검색

애플리케이션 빌드

download PDF
OpenShift Container Platform 4.13

OpenShift Container Platform에서 애플리케이션 생성 및 관리

Red Hat OpenShift Documentation Team

초록

이 문서에서는 OpenShift Container Platform에서 실행 중인 사용자 프로비저닝 애플리케이션 인스턴스를 생성하고 관리하는 다양한 방법을 설명합니다. 여기에는 Open Service Broker API를 사용하여 프로젝트 및 프로비저닝 애플리케이션을 작업하는 방법이 포함됩니다.

1장. 애플리케이션 빌드 개요

OpenShift Container Platform을 사용하면 웹 콘솔 또는 CLI(명령줄 인터페이스)를 사용하여 애플리케이션을 생성, 편집, 삭제 및 관리할 수 있습니다.

1.1. 프로젝트 작업

프로젝트를 사용하면 애플리케이션을 별도로 구성하고 관리할 수 있습니다. OpenShift Container Platform에서 프로젝트 생성, 보기, 삭제를 포함하여 전체 프로젝트 라이프사이클을 관리할 수 있습니다.

프로젝트를 생성한 후 개발자 화면을 사용하여 프로젝트에 대한 액세스 권한을 부여하거나 취소하고 사용자의 클러스터 역할을 관리할 수 있습니다. 새 프로젝트의 자동 프로비저닝에 사용되는 프로젝트 템플릿을 생성하는 동안 프로젝트 구성 리소스를 편집할 수도 있습니다.

CLI를 사용하면 OpenShift Container Platform API에 대한 요청을 가장하여 다른 사용자로 프로젝트를 생성할 수 있습니다. 새 프로젝트 생성을 요청하면 OpenShift Container Platform에서 끝점을 사용하여 사용자 지정 가능한 템플릿에 따라 프로젝트를 프로비저닝합니다. 클러스터 관리자는 인증된 사용자 그룹이 새 프로젝트를 자체 프로비저닝하지 못하도록 선택할 수 있습니다.

1.2. 애플리케이션 작업

1.2.1. 애플리케이션 생성

애플리케이션을 생성하려면 프로젝트를 생성하거나 적절한 역할 및 권한이 있는 프로젝트에 액세스할 수 있어야 합니다. 웹 콘솔의 개발자 화면,설치된 Operator 또는 OpenShift CLI(oc)를 사용하여 애플리케이션을 생성할 수 있습니다. Git, JAR 파일, devfile 또는 개발자 카탈로그에서 프로젝트에 추가할 애플리케이션을 소싱할 수 있습니다.

소스 또는 바이너리 코드, 이미지 및 템플릿이 포함된 구성 요소를 사용하여 OpenShift CLI(oc)를 사용하여 애플리케이션을 생성할 수도 있습니다. OpenShift Container Platform 웹 콘솔을 사용하면 클러스터 관리자가 설치한 Operator에서 애플리케이션을 생성할 수 있습니다.

1.2.2. 애플리케이션 유지 관리

애플리케이션을 생성한 후 웹 콘솔을 사용하여 프로젝트 또는 애플리케이션 지표를 모니터링할 수 있습니다. 웹 콘솔을 사용하여 애플리케이션을 편집하거나 삭제할 수도 있습니다.

애플리케이션이 실행 중이면 일부 애플리케이션 리소스가 사용되지는 않습니다. 클러스터 관리자는 리소스 사용을 줄이기 위해 이러한 확장 가능한 리소스를 유휴 상태로 설정하도록 선택할 수 있습니다.

1.2.3. 서비스에 애플리케이션 연결

애플리케이션은 백업 서비스를 사용하여 서비스 공급자에 따라 달라지는 워크로드를 빌드하고 연결합니다. 개발자는 Service Binding Operator 를 사용하여 바인딩 연결을 구성하는 수동 프로시저 없이 Operator 관리 백업 서비스와 함께 워크로드를 바인딩할 수 있습니다. IBM Power, IBM Z 및 IBM® LinuxONE 환경에서도 서비스 바인딩을 적용할 수 있습니다.

1.2.4. 애플리케이션 배포

Deployment 또는 DeploymentConfig오브젝트 를 사용하여 애플리케이션을 배포하고 웹 콘솔에서 관리할 수 있습니다. 애플리케이션 변경 중 또는 애플리케이션 업그레이드 중에 다운타임을 줄이는 데 도움이 되는 배포 전략을 생성할 수 있습니다.

OpenShift Container Platform 클러스터에 대한 애플리케이션 및 서비스 배포를 간소화하는 소프트웨어 패키지 관리자인 Helm 도 사용할 수 있습니다.

1.3. Red Hat Marketplace 사용

Red Hat Marketplace 는 공용 클라우드 및 온프레미스에서 실행되는 컨테이너 기반 환경을 위한 인증된 소프트웨어를 검색하고 액세스할 수 있는 오픈 클라우드 마켓플레이스입니다.

2장. 프로젝트

2.1. 노드 작업

사용자 커뮤니티는 프로젝트를 통해 다른 커뮤니티와 별도로 콘텐츠를 구성하고 관리할 수 있습니다.

참고

openshift-kube- 로 시작하는 프로젝트는 기본 프로젝트입니다. 이러한 프로젝트는 Pod 및 기타 인프라 구성 요소로 실행되는 클러스터 구성 요소를 호스팅합니다. 따라서 OpenShift Container Platform에서는 oc new-project 명령을 사용하여 openshift- 또는 kube-로 시작하는 프로젝트를 생성할 수 없습니다. 클러스터 관리자는 oc adm new-project 명령을 사용하여 이러한 프로젝트를 생성할 수 있습니다.

참고

기본 네임스페이스(default, kube-system, kube-public, openshift-node, openshift-infra, openshift) 중 하나에서 생성된 Pod에는 SCC를 할당할 수 없습니다. 이러한 네임스페이스는 Pod 또는 서비스를 실행하는 데 사용할 수 없습니다.

2.1.1. 프로젝트 생성

OpenShift Container Platform 웹 콘솔 또는 OpenShift CLI(oc)를 사용하여 클러스터에 프로젝트를 생성할 수 있습니다.

2.1.1.1. 웹 콘솔을 사용하여 프로젝트 생성

OpenShift Container Platform 웹 콘솔을 사용하여 클러스터에 프로젝트를 생성할 수 있습니다.

참고

openshift-kube-로 시작하는 프로젝트는 OpenShift Container Platform에서 중요한 것으로 간주합니다. 따라서 OpenShift Container Platform에서는 웹 콘솔을 사용하여 openshift- 로 시작하는 프로젝트를 생성할 수 없습니다.

사전 요구 사항

  • OpenShift Container Platform에서 프로젝트, 애플리케이션 및 기타 워크로드를 생성할 적절한 역할과 권한이 있는지 확인합니다.

프로세스

  • 관리자 화면을 사용하는 경우:

    1. 프로젝트로 이동합니다.
    2. 프로젝트 생성을 클릭합니다.

      1. 프로젝트 생성 대화 상자에서 이름 필드에 myproject와 같은 고유한 이름을 입력합니다.
      2. 선택 사항: 표시 이름 및 프로젝트에 대한 설명 세부 정보를 추가합니다.
      3. Create를 클릭합니다.

        프로젝트의 대시보드가 표시됩니다.

    3. 선택 사항: 세부 정보 탭을 선택하여 프로젝트 세부 정보를 확인합니다.
    4. 선택 사항: 프로젝트에 대한 적절한 권한이 있는 경우 프로젝트 액세스 탭을 사용하여 admin을 제공하거나 취소하고 프로젝트에 대한 권한을 편집 및 볼 수 있습니다.
  • 개발자 화면을 사용하는 경우:

    1. 프로젝트 메뉴를 클릭하고 프로젝트 생성을 선택합니다.

      그림 2.1. 프로젝트 생성

      odc create project
      1. 프로젝트 생성 대화 상자에서 이름 필드에 myproject와 같은 고유한 이름을 입력합니다.
      2. 선택 사항: 표시 이름 및 프로젝트에 대한 설명 세부 정보를 추가합니다.
      3. Create를 클릭합니다.
    2. 선택 사항: 왼쪽 탐색 패널을 사용하여 프로젝트 보기로 이동하여 프로젝트 대시보드를 확인합니다.
    3. 선택 사항: 프로젝트 대시보드에서 세부 정보 탭을 선택하여 프로젝트 세부 정보를 확인합니다.
    4. 선택 사항: 프로젝트에 대한 적절한 권한이 있는 경우 프로젝트 대시보드의 프로젝트 액세스 탭을 사용하여 프로젝트에 대한 관리자 또는 편집 및 보기 권한을 제공하거나 취소할 수 있습니다.
2.1.1.2. CLI를 사용하여 프로젝트 생성

클러스터 관리자가 허용한 경우 새 프로젝트를 생성할 수 있습니다.

참고

openshift-kube-로 시작하는 프로젝트는 OpenShift Container Platform에서 중요한 것으로 간주합니다. 따라서 OpenShift Container Platform에서는 oc new-project 명령을 사용하여 openshift- 또는 kube-로 시작하는 프로젝트를 생성할 수 없습니다. 클러스터 관리자는 oc adm new-project 명령을 사용하여 이러한 프로젝트를 생성할 수 있습니다.

참고

기본 네임스페이스(default, kube-system, kube-public, openshift-node, openshift-infra, openshift) 중 하나에서 생성된 Pod에는 SCC를 할당할 수 없습니다. 이러한 네임스페이스는 Pod 또는 서비스를 실행하는 데 사용할 수 없습니다.

프로세스

  • 다음을 실행합니다.

    $ oc new-project <project_name> \
        --description="<description>" --display-name="<display_name>"

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

    $ oc new-project hello-openshift \
        --description="This is an example project" \
        --display-name="Hello OpenShift"
참고

생성할 수 있는 프로젝트 수는 시스템 관리자가 제한할 수 있습니다. 제한에 도달한 후 새 프로젝트를 생성하려면 기존 프로젝트를 삭제해야 할 수 있습니다.

2.1.2. 프로젝트 보기

OpenShift Container Platform 웹 콘솔 또는 OpenShift CLI(oc)를 사용하여 클러스터의 프로젝트를 볼 수 있습니다.

2.1.2.1. 웹 콘솔을 사용하여 프로젝트 보기

OpenShift Container Platform 웹 콘솔을 사용하여 액세스할 수 있는 프로젝트를 볼 수 있습니다.

프로세스

  • 관리자 화면을 사용하는 경우:

    1. 탐색 메뉴에서 프로젝트로 이동합니다.
    2. 확인할 프로젝트를 선택합니다. 개요 탭에는 프로젝트에 대한 대시보드가 포함되어 있습니다.
    3. 프로젝트 세부 정보를 보려면 세부 정보 탭을 선택합니다.
    4. YAML 탭을 선택하여 프로젝트 리소스에 대한 YAML 구성을 보고 업데이트합니다.
    5. 워크로드 탭을 선택하여 프로젝트의 워크로드를 확인합니다.
    6. 프로젝트의 역할 바인딩을 보고 생성할 RoleBindings 탭을 선택합니다.
  • 개발자 화면을 사용하는 경우:

    1. 탐색 메뉴에서 프로젝트 페이지로 이동합니다.
    2. 화면 상단에 있는 프로젝트 드롭다운 메뉴에서 모든 프로젝트를 선택하여 클러스터의 모든 프로젝트를 나열합니다.
    3. 확인할 프로젝트를 선택합니다. 개요 탭에는 프로젝트에 대한 대시보드가 포함되어 있습니다.
    4. 프로젝트 세부 정보를 보려면 세부 정보 탭을 선택합니다.
    5. 프로젝트에 대한 적절한 권한이 있는 경우 프로젝트 액세스 탭 보기를 선택하고 프로젝트에 대한 권한을 업데이트합니다.
2.1.2.2. CLI를 사용하여 프로젝트 보기

프로젝트를 볼 때는 권한 부여 정책에 따라 볼 수 있는 액세스 권한이 있는 프로젝트만 볼 수 있습니다.

프로세스

  1. 프로젝트 목록을 보려면 다음을 실행합니다.

    $ oc get projects
  2. CLI 작업을 위해 현재 프로젝트에서 다른 프로젝트로 변경할 수 있습니다. 그러면 지정된 프로젝트가 프로젝트 범위의 콘텐츠를 조작하는 모든 후속 작업에서 사용됩니다.

    $ oc project <project_name>

2.1.3. 개발자 화면을 사용하여 프로젝트에 액세스 권한 제공

개발자 화면의 프로젝트 보기를 사용하여 프로젝트에 대한 액세스 권한을 부여하거나 취소할 수 있습니다.

사전 요구 사항

  • 프로젝트를 생성했습니다.

프로세스

프로젝트에 사용자를 추가하고 관리자, 편집 또는 보기 액세스 권한을 제공하려면 다음을 수행합니다.

  1. 개발자 화면에서 프로젝트 페이지로 이동합니다.
  2. 프로젝트 메뉴에서 프로젝트를 선택합니다.
  3. 프로젝트 액세스 탭을 선택합니다.
  4. 액세스 권한을 클릭하여 기본 권한에 새 권한 행을 추가합니다.

    그림 2.2. 프로젝트 권한

    odc project permissions
  5. 사용자 이름을 입력하고 역할 선택 드롭다운 목록을 클릭하고 적절한 역할을 선택합니다.
  6. 저장을 클릭하여 새 권한을 추가합니다.

또는 다음을 수행할 수도 있습니다.

  • 역할 선택 드롭다운 목록을 사용하여 기존 사용자의 액세스 권한을 수정합니다.
  • 액세스 제거 아이콘을 사용하여 프로젝트에 대한 기존 사용자의 액세스 권한을 완전히 제거합니다.
참고

고급 역할 기반 액세스 제어는 관리자 화면의 역할역할 바인딩 보기에서 관리됩니다.

2.1.4. 웹 콘솔을 사용하여 사용 가능한 클러스터 역할 사용자 정의

웹 콘솔의 개발자 화면에서 프로젝트 → 프로젝트 액세스 페이지를 통해 프로젝트 관리자가 프로젝트의 사용자에게 역할을 부여할 수 있습니다. 기본적으로 프로젝트의 사용자에게 부여할 수 있는 사용 가능한 클러스터 역할은 admin, edit, view입니다.

클러스터 관리자는 클러스터 전체에서 모든 프로젝트에 대한 프로젝트 액세스 페이지에서 사용할 수 있는 클러스터 역할을 정의할 수 있습니다. Console 구성 리소스에서 spec.customization.projectAccess.availableClusterRoles 오브젝트를 사용자 정의하여 사용 가능한 역할을 지정할 수 있습니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.

프로세스

  1. 관리자 관점에서 관리클러스터 설정으로 이동합니다.
  2. 구성 탭을 클릭합니다.
  3. 구성 리소스 목록에서 Console operator.openshift.io 를 선택합니다.
  4. YAML 탭으로 이동하여 YAML 코드를 보고 편집합니다.
  5. spec 아래의 YAML 코드에서 프로젝트 액세스에 대해 사용 가능한 클러스터 역할 목록을 사용자 지정합니다. 다음 예제에서는 기본 admin,editview 역할을 지정합니다.

    apiVersion: operator.openshift.io/v1
    kind: Console
    metadata:
      name: cluster
    # ...
    spec:
      customization:
        projectAccess:
          availableClusterRoles:
          - admin
          - edit
          - view
  6. 저장을 클릭하여 콘솔 구성 리소스에 대한 변경 사항을 저장합니다.

검증

  1. 개발자 화면에서 프로젝트 페이지로 이동합니다.
  2. 프로젝트 메뉴에서 프로젝트를 선택합니다.
  3. 프로젝트 액세스 탭을 선택합니다.
  4. Role (역할) 열에서 메뉴를 클릭하고 사용 가능한 역할이 Console 리소스 구성에 적용한 구성과 일치하는지 확인합니다.

2.1.5. 프로젝트에 추가

개발자 화면의 +추가 페이지를 사용하여 프로젝트에 항목을 추가할 수 있습니다.

사전 요구 사항

  • 프로젝트를 생성했습니다.

프로세스

  1. 개발자 화면에서 +추가 페이지로 이동합니다.
  2. 프로젝트 메뉴에서 프로젝트를 선택합니다.
  3. +추가 페이지에서 항목을 클릭한 다음 워크플로우를 따릅니다.
참고

추가* 페이지의 검색 기능을 사용하여 프로젝트에 추가할 추가 항목을 찾을 수도 있습니다. 페이지 상단에 있는 추가 에서 * 를 클릭하고 검색 필드에 구성 요소의 이름을 입력합니다.

2.1.6. 프로젝트 상태 확인

OpenShift Container Platform 웹 콘솔 또는 OpenShift CLI(oc)를 사용하여 프로젝트의 상태를 볼 수 있습니다.

2.1.6.1. 웹 콘솔을 사용하여 프로젝트 상태 확인

웹 콘솔을 사용하여 프로젝트의 상태를 검토할 수 있습니다.

사전 요구 사항

  • 프로젝트를 생성했습니다.

프로세스

  • 관리자 화면을 사용하는 경우:

    1. 프로젝트로 이동합니다.
    2. 목록에서 프로젝트를 선택합니다.
    3. 개요 페이지에서 프로젝트 상태를 검토합니다.
  • 개발자 화면을 사용하는 경우:

    1. 프로젝트 페이지로 이동합니다.
    2. 프로젝트 메뉴에서 프로젝트를 선택합니다.
    3. 개요 페이지에서 프로젝트 상태를 검토합니다.
2.1.6.2. CLI를 사용하여 프로젝트 상태 확인

OpenShift CLI(oc)를 사용하여 프로젝트의 상태를 검토할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • 프로젝트를 생성했습니다.

프로세스

  1. 프로젝트로 전환합니다.

    $ oc project <project_name> 1
    1
    & lt;project_name >을 프로젝트 이름으로 바꿉니다.
  2. 프로젝트의 상위 수준 개요를 가져옵니다.

    $ oc status

2.1.7. 프로젝트 삭제

OpenShift Container Platform 웹 콘솔 또는 OpenShift CLI(oc)를 사용하여 프로젝트를 삭제할 수 있습니다.

프로젝트를 삭제하면 서버에서 프로젝트 상태를 활성에서 종료로 업데이트합니다. 그런 다음 서버는 프로젝트를 완전히 제거하기 전에 상태가 종료인 프로젝트의 모든 콘텐츠를 지웁니다. 프로젝트 상태가 종료인 동안에는 프로젝트에 새 콘텐츠를 추가할 수 없습니다. CLI 또는 웹 콘솔에서 프로젝트를 삭제할 수 있습니다.

2.1.7.1. 웹 콘솔을 사용하여 프로젝트 삭제

웹 콘솔을 사용하여 프로젝트를 삭제할 수 있습니다.

사전 요구 사항

  • 프로젝트를 생성했습니다.
  • 프로젝트를 삭제하는 데 필요한 권한이 있습니다.

프로세스

  • 관리자 화면을 사용하는 경우:

    1. 프로젝트로 이동합니다.
    2. 목록에서 프로젝트를 선택합니다.
    3. 프로젝트의 작업 드롭다운 메뉴를 클릭하고 프로젝트 삭제 를 선택합니다.

      참고

      프로젝트를 삭제하는 데 필요한 권한이 없는 경우 프로젝트 삭제 옵션을 사용할 수 없습니다.

      1. Delete Project? 창에서 프로젝트 이름을 입력하여 삭제를 확인합니다.
      2. 삭제를 클릭합니다.
  • 개발자 화면을 사용하는 경우:

    1. 프로젝트 페이지로 이동합니다.
    2. 프로젝트 메뉴에서 삭제할 프로젝트를 선택합니다.
    3. 프로젝트의 작업 드롭다운 메뉴를 클릭하고 프로젝트 삭제 를 선택합니다.

      참고

      프로젝트를 삭제하는 데 필요한 권한이 없는 경우 프로젝트 삭제 옵션을 사용할 수 없습니다.

      1. Delete Project? 창에서 프로젝트 이름을 입력하여 삭제를 확인합니다.
      2. 삭제를 클릭합니다.
2.1.7.2. CLI를 사용하여 프로젝트 삭제

OpenShift CLI(oc)를 사용하여 프로젝트를 삭제할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • 프로젝트를 생성했습니다.
  • 프로젝트를 삭제하는 데 필요한 권한이 있습니다.

프로세스

  1. 프로젝트를 삭제합니다.

    $ oc delete project <project_name> 1
    1
    & lt;project_name >을 삭제하려는 프로젝트의 이름으로 바꿉니다.

2.2. 다른 사용자로 프로젝트 생성

가장 기능을 사용하면 다른 사용자로 프로젝트를 생성할 수 있습니다.

2.2.1. API 가장

OpenShift Container Platform API에 대한 요청을 다른 사용자가 보낸 것처럼 작동하도록 구성할 수 있습니다. 자세한 내용은 Kubernetes 설명서의 사용자 가장을 참조하십시오.

2.2.2. 프로젝트를 만들 때 사용자 가장

프로젝트 요청을 생성할 때 다른 사용자로 가장할 수 있습니다. system:authenticated:oauth는 프로젝트 요청을 생성할 수 있는 유일한 부트스트랩 그룹이므로 이 그룹을 가장해야 합니다.

프로세스

  • 다른 사용자를 대신하여 프로젝트 요청을 생성하려면 다음을 실행합니다.

    $ oc new-project <project> --as=<user> \
        --as-group=system:authenticated --as-group=system:authenticated:oauth

2.3. 프로젝트 생성 구성

OpenShift Container Platform에서 프로젝트는 관련 오브젝트를 그룹화하고 격리하는 데 사용됩니다. 웹 콘솔 또는 oc new-project 명령을 사용하여 새 프로젝트를 생성하라는 요청이 생성되면 OpenShift Container Platform의 끝점을 사용하여 사용자 지정할 수 있는 템플릿에 따라 프로젝트를 프로비저닝합니다.

클러스터 관리자는 개발자 및 서비스 계정이 자체 프로젝트를 생성하거나 자체 프로비저닝하는 방법을 허용하고 구성할 수 있습니다.

2.3.1. 프로젝트 생성 정보

OpenShift Container Platform API 서버는 클러스터의 프로젝트 구성 리소스에서 projectRequestTemplate 매개변수로 식별하는 프로젝트 템플릿을 기반으로 새 프로젝트를 자동으로 프로비저닝합니다. 매개변수가 정의되지 않은 경우 API 서버는 요청된 이름으로 프로젝트를 생성하는 기본 템플릿을 생성하고 요청하는 사용자에게 해당 프로젝트의 admin 역할을 할당합니다.

프로젝트 요청을 제출하면 API에서 다음 매개변수를 템플릿으로 대체합니다.

표 2.1. 기본 프로젝트 템플릿 매개변수
매개변수설명

PROJECT_NAME

프로젝트 이름입니다. 필수 항목입니다.

PROJECT_DISPLAYNAME

프로젝트의 표시 이름입니다. 비어 있을 수 있습니다.

PROJECT_DESCRIPTION

프로젝트에 대한 설명입니다. 비어 있을 수 있습니다.

PROJECT_ADMIN_USER

관리 사용자의 사용자 이름입니다.

PROJECT_REQUESTING_USER

요청하는 사용자의 사용자 이름입니다.

API에 대한 액세스 권한은 self-provisioner 역할 및 self-provisioner 클러스터 역할 바인딩을 가진 개발자에게 부여됩니다. 이 역할은 기본적으로 인증된 모든 개발자에게 제공됩니다.

2.3.2. 새 프로젝트의 템플릿 수정

클러스터 관리자는 사용자 정의 요구 사항을 사용하여 새 프로젝트를 생성하도록 기본 프로젝트 템플릿을 수정할 수 있습니다.

사용자 정의 프로젝트 템플릿을 만들려면:

프로세스

  1. cluster-admin 권한이 있는 사용자로 로그인합니다.
  2. 기본 프로젝트 템플릿을 생성합니다.

    $ oc adm create-bootstrap-project-template -o yaml > template.yaml
  3. 텍스트 편집기를 사용하여 오브젝트를 추가하거나 기존 오브젝트를 수정하여 생성된 template.yaml 파일을 수정합니다.
  4. 프로젝트 템플릿은 openshift-config 네임스페이스에서 생성해야 합니다. 수정된 템플릿을 불러옵니다.

    $ oc create -f template.yaml -n openshift-config
  5. 웹 콘솔 또는 CLI를 사용하여 프로젝트 구성 리소스를 편집합니다.

    • 웹 콘솔에 액세스:

      1. 관리클러스터 설정으로 이동합니다.
      2. Configuration 을 클릭하여 모든 구성 리소스를 확인합니다.
      3. 프로젝트 항목을 찾아 YAML 편집을 클릭합니다.
    • CLI 사용:

      1. 다음과 같이 project.config.openshift.io/cluster 리소스를 편집합니다.

        $ oc edit project.config.openshift.io/cluster
  6. projectRequestTemplatename 매개변수를 포함하도록 spec 섹션을 업데이트하고 업로드된 프로젝트 템플릿의 이름을 설정합니다. 기본 이름은 project-request입니다.

    사용자 정의 프로젝트 템플릿이 포함된 프로젝트 구성 리소스

    apiVersion: config.openshift.io/v1
    kind: Project
    metadata:
    # ...
    spec:
      projectRequestTemplate:
        name: <template_name>
    # ...

  7. 변경 사항을 저장한 후 새 프로젝트를 생성하여 변경 사항이 성공적으로 적용되었는지 확인합니다.

2.3.3. 프로젝트 자체 프로비저닝 비활성화

인증된 사용자 그룹이 새 프로젝트를 자체 프로비저닝하지 못하도록 할 수 있습니다.

프로세스

  1. cluster-admin 권한이 있는 사용자로 로그인합니다.
  2. 다음 명령을 실행하여 self-provisioners 클러스터 역할 바인딩 사용을 확인합니다.

    $ oc describe clusterrolebinding.rbac self-provisioners

    출력 예

    Name:		self-provisioners
    Labels:		<none>
    Annotations:	rbac.authorization.kubernetes.io/autoupdate=true
    Role:
      Kind:	ClusterRole
      Name:	self-provisioner
    Subjects:
      Kind	Name				Namespace
      ----	----				---------
      Group	system:authenticated:oauth

    self-provisioners 섹션의 제목을 검토합니다.

  3. 그룹 system:authenticated:oauth에서 self-provisioner 클러스터 역할을 제거합니다.

    • self-provisioners 클러스터 역할 바인딩에서 self-provisioner 역할을 system:authenticated:oauth 그룹에만 바인딩하는 경우 다음 명령을 실행합니다.

      $ oc patch clusterrolebinding.rbac self-provisioners -p '{"subjects": null}'
    • self-provisioners 클러스터 역할 바인딩에서 self-provisioner 역할을 system:authenticated:oauth 그룹 이외에도 추가 사용자, 그룹 또는 서비스 계정에 바인딩하는 경우 다음 명령을 실행합니다.

      $ oc adm policy \
          remove-cluster-role-from-group self-provisioner \
          system:authenticated:oauth
  4. 역할이 자동으로 업데이트되지 않도록 self-provisioners 클러스터 역할 바인딩을 편집합니다. 역할이 자동으로 업데이트되면 클러스터 역할이 기본 상태로 재설정됩니다.

    • CLI를 사용하여 역할 바인딩을 업데이트하려면 다음을 수행합니다.

      1. 다음 명령을 실행합니다.

        $ oc edit clusterrolebinding.rbac self-provisioners
      2. 표시된 역할 바인딩에서 다음 예와 같이 rbac.authorization.kubernetes.io/autoupdate 매개변수 값을 false로 설정합니다.

        apiVersion: authorization.openshift.io/v1
        kind: ClusterRoleBinding
        metadata:
          annotations:
            rbac.authorization.kubernetes.io/autoupdate: "false"
        # ...
    • 단일 명령을 사용하여 역할 바인딩을 업데이트하려면 다음을 실행합니다.

      $ oc patch clusterrolebinding.rbac self-provisioners -p '{ "metadata": { "annotations": { "rbac.authorization.kubernetes.io/autoupdate": "false" } } }'
  5. 인증된 사용자로 로그인하여 프로젝트를 더 이상 자체 프로비저닝할 수 없는지 확인합니다.

    $ oc new-project test

    출력 예

    Error from server (Forbidden): You may not request a new project via this API.

    조직과 관련된 더 유용한 지침을 제공하도록 이 프로젝트 요청 메시지를 사용자 정의하는 것이 좋습니다.

2.3.4. 프로젝트 요청 메시지 사용자 정의

프로젝트를 자체 프로비저닝할 수 없는 개발자 또는 서비스 계정이 웹 콘솔 또는 CLI를 사용하여 프로젝트 생성을 요청하면 기본적으로 다음과 같은 오류 메시지가 반환됩니다.

You may not request a new project via this API.

클러스터 관리자는 이 메시지를 사용자 지정할 수 있습니다. 조직과 관련된 새 프로젝트를 요청하는 방법에 대한 추가 지침을 제공하려면 업데이트하는 것이 좋습니다. 예를 들면 다음과 같습니다.

  • 프로젝트를 요청하려면 projectname@example.com을 통해 시스템 관리자에게 문의하십시오.
  • 새 프로젝트를 요청하려면 https://internal.example.com/openshift-project-request에 있는 프로젝트 요청 양식을 작성합니다.

프로젝트 요청 메시지를 사용자 지정하려면 다음을 수행합니다.

프로세스

  1. 웹 콘솔 또는 CLI를 사용하여 프로젝트 구성 리소스를 편집합니다.

    • 웹 콘솔에 액세스:

      1. 관리클러스터 설정으로 이동합니다.
      2. Configuration 을 클릭하여 모든 구성 리소스를 확인합니다.
      3. 프로젝트 항목을 찾아 YAML 편집을 클릭합니다.
    • CLI 사용:

      1. cluster-admin 권한이 있는 사용자로 로그인합니다.
      2. 다음과 같이 project.config.openshift.io/cluster 리소스를 편집합니다.

        $ oc edit project.config.openshift.io/cluster
  2. projectRequestMessage 매개변수를 포함하도록 spec 섹션을 업데이트하고 해당 값을 사용자 정의 메시지로 설정합니다.

    사용자 정의 프로젝트 요청 메시지가 포함된 프로젝트 구성 리소스

    apiVersion: config.openshift.io/v1
    kind: Project
    metadata:
    # ...
    spec:
      projectRequestMessage: <message_string>
    # ...

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

    apiVersion: config.openshift.io/v1
    kind: Project
    metadata:
    # ...
    spec:
      projectRequestMessage: To request a project, contact your system administrator at projectname@example.com.
    # ...
  3. 변경 사항을 저장한 후 프로젝트를 자체 프로비저닝하여 변경 사항이 성공적으로 적용되었는지 확인할 수 없는 개발자 또는 서비스 계정으로 새 프로젝트를 생성합니다.

3장. 애플리케이션 생성

3.1. 개발자 화면을 사용하여 애플리케이션 생성

웹 콘솔의 개발자 화면은 +추가 보기에서 애플리케이션 및 관련 서비스를 생성하고 OpenShift Container Platform에 배포할 수 있는 다음 옵션을 제공합니다.

  • 시작하기 리소스: 이러한 리소스를 사용하여 개발자 콘솔을 시작할 수 있습니다. 옵션 메뉴 kebab 를 사용하여 헤더를 숨기도록 선택할 수 있습니다.

    • 샘플을 사용하여 애플리케이션 생성: 기존 코드 샘플을 사용하여 OpenShift Container Platform에서 애플리케이션 생성을 시작합니다.
    • 가이드 문서 빌드: 관련 문서에 따라 애플리케이션을 빌드하고 주요 개념과 용어에 숙지하십시오.
    • 새로운 개발자 기능 살펴보기: 개발자 화면 내에서 새로운 기능과 리소스를 탐색합니다.
  • 개발자 카탈로그: 이미지 빌더에 필요한 애플리케이션, 서비스 또는 소스를 선택한 다음 프로젝트에 추가하려면 개발자 카탈로그를 탐색합니다.

    • 모든 서비스: 카탈로그를 검색하여 OpenShift Container Platform에서 서비스를 검색합니다.
    • 데이터베이스: 필요한 데이터베이스 서비스를 선택하고 애플리케이션에 추가합니다.
    • Operator Backed: Operator 관리 필요한 서비스를 선택하고 배포합니다.
    • Helm 차트: 애플리케이션 및 서비스 배포를 간소화하는 데 필요한 Helm 차트를 선택합니다.
    • devfile: Devfile 레지스트리에서 개발 환경을 선언적으로 정의하도록 devfile을 선택합니다.
    • 이벤트 소스: 특정 시스템의 이벤트 클래스에 대한 관심을 등록할 이벤트 소스를 선택합니다.

      참고

      RHOAS Operator가 설치된 경우에도 Managed services 옵션을 사용할 수 있습니다.

  • Git 리포지토리: From Git, Devfile , 또는 Dockerfile 옵션에서 각각 사용하여 Git 리포지토리에서 기존 코드베이스, Devfile 또는 Dockerfile을 가져와서 OpenShift Container Platform에서 애플리케이션을 빌드하고 배포합니다.
  • 컨테이너 이미지: 이미지 스트림 또는 레지스트리의 기존 이미지를 사용하여 OpenShift Container Platform에 배포합니다.
  • Pipeline: OpenShift Container Platform에서 소프트웨어 제공 프로세스를 위해 Tekton 파이프라인을 사용하여 CI/CD 파이프라인을 생성합니다.
  • 서버리스: OpenShift Container Platform에서 상태 비저장 및 서버리스 애플리케이션을 생성, 빌드, 배포하기 위해 Serverless 옵션을 탐색합니다.

    • 채널: 메모리 내 및 안정적인 구현을 사용하여 이벤트 전달 및 지속성 계층을 생성하기 위해 Knative 채널을 생성합니다.
  • 샘플: 애플리케이션을 빠르게 생성, 빌드 및 배포하는 데 사용할 수 있는 샘플 애플리케이션을 탐색합니다.
  • 빠른 시작: 빠른 시작 옵션을 탐색하여 단계별 지침 및 작업을 사용하여 애플리케이션을 생성, 가져오기 및 실행합니다.
  • 로컬 시스템에서: 애플리케이션을 쉽게 빌드하고 배포하기 위해 로컬 머신에서 파일을 가져오거나 업로드할 수 있도록 로컬 머신 타일을 탐색합니다.

    • Import YAML: YAML 파일을 업로드하여 애플리케이션을 빌드하고 배포하기 위한 리소스를 생성하고 정의합니다.
    • JAR 파일 업로드: JAR 파일을 업로드하여 Java 애플리케이션을 빌드하고 배포합니다.
  • 내 프로젝트 공유:이 옵션을 사용하여 프로젝트에 사용자를 추가하거나 제거하고 접근성 옵션을 제공합니다.
  • Helm 차트 리포지터리: 이 옵션을 사용하여 네임스페이스에 Helm 차트 리포지터리를 추가합니다.
  • 리소스 순서를 다시 정렬 합니다. 이러한 리소스를 사용하여 탐색 창에 추가된 고정된 리소스를 다시 정렬합니다. 탐색 창에서 마우스를 가리킬 때 고정된 리소스의 왼쪽에 드래그 앤 드롭 아이콘이 표시됩니다. 드래그된 리소스는 해당 리소스가 있는 섹션에서만 삭제할 수 있습니다.

파이프라인,이벤트 소스가상 머신 가져오기 와 같은 특정 옵션은 OpenShift Pipelines Operator,OpenShift Serverless OperatorOpenShift Virtualization Operator 가 각각 설치된 경우에만 표시됩니다.

3.1.1. 사전 요구 사항

개발자 화면을 사용하여 애플리케이션을 생성하려면 다음 조건을 충족해야 합니다.

서버리스 애플리케이션을 생성하려면 위 사전 요구 사항에 다음 조건이 추가됩니다.

3.1.2. 샘플 애플리케이션 생성

개발자 화면의 +추가 흐름에서 샘플 애플리케이션을 사용하여 애플리케이션을 빠르게 생성, 빌드 및 배포할 수 있습니다.

사전 요구 사항

  • OpenShift Container Platform 웹 콘솔에 로그인하여 개발자 화면에 있습니다.

절차

  1. +추가 보기에서 샘플 타일을 클릭하여 샘플 페이지를 확인합니다.
  2. 샘플 페이지에서 사용 가능한 샘플 애플리케이션 중 하나를 선택하여 샘플 애플리케이션 생성 양식을 확인합니다.
  3. 샘플 애플리케이션 생성 양식에서 다음을 수행합니다.

    • 이름 필드에는 기본적으로 배포 이름이 표시됩니다. 필요에 따라 이 이름을 수정할 수 있습니다.
    • 빌더 이미지 버전에는 빌더 이미지가 기본적으로 선택되어 있습니다. 빌더 이미지 버전 드롭다운 목록을 사용하여 이 이미지 버전을 수정할 수 있습니다.
    • 샘플 Git 리포지토리 URL이 기본적으로 추가됩니다.
  4. 생성을 클릭하여 샘플 애플리케이션을 생성합니다. 샘플 애플리케이션의 빌드 상태가 토폴로지 보기에 표시됩니다. 샘플 애플리케이션이 생성되면 애플리케이션에 추가된 배포를 볼 수 있습니다.

3.1.3. 빠른 시작을 사용하여 애플리케이션 생성

빠른 시작 페이지에는 단계별 지침 및 작업을 사용하여 OpenShift Container Platform에서 애플리케이션을 생성, 가져오기 및 실행하는 방법을 보여줍니다.

사전 요구 사항

  • OpenShift Container Platform 웹 콘솔에 로그인하여 개발자 화면에 있습니다.

절차

  1. +추가 보기에서 시작하기 리소스안내 문서로 빌드모든 퀵 스타트 링크를 클릭하여 빠른 시작 페이지를 확인합니다.
  2. 빠른 시작 페이지에서 사용하려는 퀵 스타트의 타일을 클릭합니다.
  3. 시작을 클릭하여 퀵 스타트 를 시작합니다.
  4. 표시되는 단계를 수행합니다.

3.1.4. Git에서 코드베이스를 가져와 애플리케이션 생성

개발자 화면에서는 GitHub의 기존 코드베이스를 사용하여 OpenShift Container Platform에 애플리케이션을 생성, 빌드, 배포할 수 있습니다.

다음 절차에서는 개발자 화면의 Git에서 옵션을 통해 애플리케이션을 생성합니다.

절차

  1. +추가 보기에서 Git 리포지토리 타일 에서 Git에서 를 클릭하여 Git 에서 가져오기 양식을 확인합니다.
  2. Git 섹션에서 애플리케이션을 생성하는 데 사용할 코드베이스의 Git 리포지토리 URL을 입력합니다. 예를 들어 이 샘플 Node.js 애플리케이션의 URL https://github.com/sclorg/nodejs-ex를 입력합니다. 그런 다음 URL을 검증합니다.
  3. 선택 사항: 고급 Git 옵션 표시를 클릭하여 다음과 같은 세부 정보를 추가할 수 있습니다.

    • Git 참조: 애플리케이션을 빌드하는 데 사용할 특정 분기의 코드, 태그 또는 커밋을 가리킵니다.
    • 컨텍스트 디렉터리: 애플리케이션을 빌드하는 데 사용할 애플리케이션 소스 코드의 하위 디렉터리를 지정합니다.
    • 소스 시크릿: 프라이빗 리포지토리에서 소스 코드를 가져올 수 있는 자격 증명이 포함된 시크릿 이름을 생성합니다.
  4. 선택 사항: Devfile, Dockerfile,Builder Image 또는 Serverless 기능을 Git 리포지토리를 통해 가져와서 배포를 추가로 사용자 지정할 수 있습니다.

    • Git 리포지토리에 Devfile, Dockerfile, Builder Image 또는 func.yaml 이 포함된 경우 각 경로 필드에 자동으로 탐지되어 채워집니다.
    • Devfile, Dockerfile 또는 빌더 이미지가 동일한 리포지토리에서 탐지되면 기본적으로 Devfile 이 선택됩니다.
    • Git 리포지토리에서 func.yaml 이 탐지되면 Import StrategyServerless Function 로 변경됩니다.
    • 또는 Git 리포지토리 URL을 사용하여 +추가 보기에서 Serverless 함수 생성을 클릭하여 서버리스 기능을 생성할 수 있습니다.
    • 파일 가져오기 유형을 편집하고 다른 전략을 선택하려면 Edit import strategy 옵션을 클릭합니다.
    • Devfiles, Dockerfiles 또는 Builder Images 가 여러 개 감지되면 특정 인스턴스를 가져오려면 컨텍스트 디렉터리와 관련된 각 경로를 지정합니다.
  5. Git URL을 검증한 후 권장 빌더 이미지가 선택되어 별이 표시됩니다. 빌더 이미지가 자동으로 탐지되지 않으면 빌더 이미지를 선택합니다. https://github.com/sclorg/nodejs-ex Git URL의 경우 기본적으로 Node.js 빌더 이미지가 선택됩니다.

    1. 선택 사항: 빌더 이미지 버전 드롭다운을 사용하여 버전을 지정합니다.
    2. 선택 사항: Edit import 전략을 사용하여 다른 전략을 선택합니다.
    3. 선택 사항: Node.js 빌더 이미지의 경우 Run command 필드를 사용하여 애플리케이션을 실행합니다.
  6. 일반 섹션에서 다음을 수행합니다.

    1. 애플리케이션 필드에서 애플리케이션 그룹화에 대한 고유 이름을 입력합니다(예: myapp). 애플리케이션 이름이 네임스페이스에서 고유해야 합니다.
    2. 기존 애플리케이션이 없는 경우 이 애플리케이션에 대해 생성된 리소스를 확인하는 이름 필드는 Git 리포지토리 URL에 따라 자동으로 채워집니다. 기존 애플리케이션이 있는 경우에는 기존 애플리케이션 내에 구성 요소를 배포하거나 새 애플리케이션을 생성하거나 구성 요소를 할당하지 않은 상태로 유지하도록 선택할 수 있습니다.

      참고

      리소스 이름은 네임스페이스에서 고유해야 합니다. 오류가 발생하면 리소스 이름을 수정합니다.

  7. 리소스 섹션에서 다음 옵션을 선택합니다.

    • 배포: 일반 Kubernetes 형식으로 애플리케이션을 생성합니다.
    • 배포 구성: OpenShift Container Platform 스타일 애플리케이션을 생성합니다.
    • 서버리스 배포: Knative 서비스를 생성합니다.

      참고

      애플리케이션 가져오기에 대한 기본 리소스 기본 설정을 설정하려면 사용자 환경 → 애플리케이션 → 리소스 유형 필드로 이동합니다. Serverless Deployment 옵션은 OpenShift Serverless Operator가 클러스터에 설치된 경우에만 Git에서 가져오기 양식에 표시됩니다. 서버리스 기능을 생성하는 동안 리소스 섹션을 사용할 수 없습니다. 자세한 내용은 OpenShift Serverless 설명서를 참조하십시오.

  8. 파이프라인 섹션에서 파이프라인 추가를 선택한 다음 파이프라인 시각화 표시를 클릭하여 애플리케이션의 파이프라인을 확인합니다. 기본 파이프라인이 선택되지만 애플리케이션에 사용 가능한 파이프라인 목록에서 원하는 파이프라인을 선택할 수 있습니다.

    참고

    다음 기준이 충족되면 기본적으로 파이프라인 추가 확인란이 선택되고 PAC 구성이 선택됩니다.

    • Pipeline Operator가 설치됨
    • 파이프라인을 코드로 활성화
    • Git 리포지토리에서 . Tekton 디렉터리가 검색됨
  9. 리포지토리에 Webhook를 추가합니다. Configure PAC is checked and the GitHub App is set up, see the Use GitHub App and Setup a webhook options. GitHub App을 설정하지 않은 경우 웹 후크 설정 옵션만 볼 수 있습니다.

    1. SettingsWebhooks 로 이동하여 Webhook 추가 를 클릭합니다.
    2. Payload URL 을 코드 컨트롤러 공용 URL로 Pipeline에 설정합니다.
    3. 콘텐츠 유형을 application/json 으로 선택합니다.
    4. 웹 후크 시크릿을 추가하고 대체 위치에 기록해 둡니다. openssl 이 로컬 시스템에 설치되어 있으면 임의의 시크릿을 생성합니다.
    5. Let me select individual events and select these events: Commit 댓글,Issue comments ,Pull request, Pushes 를 선택합니다.
    6. Webhook 추가를 클릭합니다.
  10. 선택 사항: 고급 옵션 섹션에서 공개적으로 사용 가능한 URL을 사용하여 애플리케이션에 액세스할 수 있도록 대상 포트 및 애플리케이션에 대한 경로 생성이 기본적으로 선택됩니다.

    애플리케이션이 기본 공용 포트 80에 데이터를 노출하지 않는 경우 확인란을 지우고 노출하려는 대상 포트 번호를 설정합니다.

  11. 선택 사항: 다음 고급 옵션을 사용하여 애플리케이션을 추가로 사용자 지정할 수 있습니다.

    라우팅

    라우팅 링크를 클릭하면 다음 작업을 수행할 수 있습니다.

    • 경로의 호스트 이름을 사용자 지정합니다.
    • 라우터에서 감시하는 경로를 지정합니다.
    • 드롭다운 목록에서 트래픽의 대상 포트를 선택합니다.
    • Secure Route 확인란을 선택하여 경로를 보호합니다. 필요한 TLS 종료 유형을 선택하고 해당 드롭다운 목록에서 안전하지 않은 트래픽에 대한 정책을 설정합니다.

      참고

      서버리스 애플리케이션의 경우 Knative 서비스는 위의 모든 라우팅 옵션을 관리합니다. 그러나 필요한 경우 트래픽에 대한 대상 포트를 사용자 지정할 수 있습니다. 대상 포트를 지정하지 않으면 기본 포트 8080이 사용됩니다.

    도메인 매핑

    Serverless Deployment 를 생성하는 경우 생성 중에 Knative 서비스에 사용자 정의 도메인 매핑을 추가할 수 있습니다.

    • 고급 옵션 섹션에서 Show advanced Routing options 를 클릭합니다.

      • 서비스에 매핑하려는 도메인 매핑 CR이 이미 존재하는 경우 도메인 매핑 드롭다운 메뉴에서 선택할 수 있습니다.
      • 새 도메인 매핑 CR을 생성하려면 도메인에 이름을 상자에 입력하고 Create 옵션을 선택합니다. 예를 들어 example.com 을 입력하면 Create 옵션은 Create "example.com" 입니다.
    상태 점검

    애플리케이션에 준비 상태, 활성 상태, 시작 프로브를 추가하려면 상태 점검 링크를 클릭합니다. 모든 프로브에는 기본 데이터가 미리 채워져 있습니다. 기본 데이터가 포함된 프로브를 추가하거나 필요에 따라 사용자 지정할 수 있습니다.

    상태 프로브를 사용자 지정하려면 다음을 수행합니다.

    • 필요한 경우 준비 상태 프로브 추가를 클릭하여 컨테이너에서 요청을 처리할 준비가 되었는지 확인하도록 매개변수를 수정하고 확인 표시를 선택하여 프로브를 추가합니다.
    • 필요한 경우 활성 상태 프로브 추가를 클릭하여 컨테이너가 아직 실행되고 있는지 확인하도록 매개변수를 수정하고 확인 표시를 선택하여 프로브를 추가합니다.
    • 필요한 경우 시작 프로브 추가를 클릭하여 컨테이너 내 애플리케이션이 시작되었는지 확인하도록 매개변수를 수정하고 확인 표시를 선택하여 프로브를 추가합니다.

      각 프로브의 드롭다운 목록에서 요청 유형을 HTTP GET, 컨테이너 명령 또는 TCP 소켓으로 지정할 수 있습니다. 선택한 요청 유형에 따라 양식이 변경됩니다. 그런 다음 기타 매개변수(예: 프로브의 성공 및 실패 임계값, 컨테이너를 시작한 후 첫 번째 프로브를 수행할 때까지의 시간(초), 프로브 빈도, 시간 제한 값)에 대한 기본값을 수정할 수 있습니다.

    빌드 구성 및 배포

    빌드 구성배포 링크를 클릭하여 해당 구성 옵션을 확인합니다. 일부 옵션은 기본적으로 선택되어 있습니다. 필요한 트리거 및 환경 변수를 추가하여 추가로 사용자 지정할 수 있습니다.

    서버리스 애플리케이션의 경우 DeploymentConfig 리소스 대신 Knative 구성 리소스에서 배포에 필요한 상태를 유지 관리하므로 Deployment 옵션이 표시되지 않습니다.

    스케일링

    처음에 배포할 애플리케이션의 Pod 수 또는 인스턴스 수를 정의하려면 스케일링 링크를 클릭합니다.

    서버리스 배포를 생성하는 경우 다음 설정도 구성할 수 있습니다.

    • min Pods 는 Knative 서비스의 지정된 시간에 실행해야 하는 Pod 수에 대한 하한을 결정합니다. 이를 minScale 설정이라고도 합니다.
    • Max Pods 는 Knative 서비스에 대해 언제든지 실행할 수 있는 Pod 수의 상한값을 결정합니다. 이를 maxScale 설정이라고도 합니다.
    • 동시성 대상은 지정된 시간에 애플리케이션 인스턴스에 필요한 동시 요청 수를 결정합니다.
    • 동시성 제한은 특정 시간에 애플리케이션 인스턴스에 허용되는 동시 요청 수에 대한 제한을 결정합니다.
    • 동시성 사용률 은 Knative에서 추가 트래픽을 처리하기 위해 추가 Pod를 확장하기 전에 충족해야 하는 동시 요청 제한의 백분율을 결정합니다.
    • 자동 스케일링 창은 자동 스케일러가 패닉 모드가 아닌 경우 스케일링 결정에 대한 입력을 제공하기 위해 평균되는 시간 창을 정의합니다. 이 기간 동안 요청이 수신되지 않으면 서비스가 0으로 확장됩니다. 자동 스케일링 창의 기본 기간은 60s 입니다. 이를 stable 창이라고도 합니다.
    리소스 제한
    컨테이너 실행 시 컨테이너에서 사용하도록 보장하거나 허용하는 CPU메모리 리소스의 양을 설정하려면 리소스 제한 링크를 클릭합니다.
    라벨
    라벨 링크를 클릭하여 애플리케이션에 사용자 정의 라벨을 추가합니다.
  12. 만들기를 클릭하여 애플리케이션을 생성하고 성공 알림이 표시됩니다. 토폴로지 보기에서 애플리케이션의 빌드 상태를 확인할 수 있습니다.

3.1.5. JAR 파일을 업로드하여 Java 애플리케이션 배포

웹 콘솔 개발자 화면을 사용하여 다음 옵션을 사용하여 JAR 파일을 업로드할 수 있습니다.

  • 개발자 화면의 +추가 보기로 이동하여 From Local Machine 타일에서 JAR 파일 업로드 를 클릭합니다. JAR 파일을 찾아 선택하거나 JAR 파일을 드래그하여 애플리케이션을 배포합니다.
  • 토폴로지 보기로 이동하고 JAR 파일 업로드 옵션을 사용하거나 JAR 파일을 드래그하여 애플리케이션을 배포합니다.
  • 토폴로지 보기에서 in-context 메뉴를 사용한 다음 JAR 파일 업로드 옵션을 사용하여 JAR 파일을 업로드하여 애플리케이션을 배포합니다.

사전 요구 사항

  • Cluster Samples Operator는 클러스터 관리자가 설치해야 합니다.
  • OpenShift Container Platform 웹 콘솔에 액세스할 수 있으며 개발자 화면에 있습니다.

프로세스

  1. 토폴로지 보기에서 아무 곳이나 마우스 오른쪽 버튼으로 클릭하여 프로젝트에 추가 메뉴를 확인합니다.
  2. Add to Project 메뉴 위로 마우스를 올리면 메뉴 옵션을 확인한 다음 JAR 파일 업로드 옵션을 선택하여 JAR 파일 업로드 폼을 확인합니다. 또는 JAR 파일을 토폴로지 보기로 드래그할 수 있습니다.
  3. JAR 파일 필드에서 로컬 시스템에 필요한 JAR 파일을 찾아 업로드합니다. 또는 JAR 파일을 필드로 드래그할 수 있습니다. 호환되지 않는 파일 유형을 토폴로지 보기로 드래그하면 오른쪽 상단에 경고가 표시됩니다. 호환되지 않는 파일 유형이 업로드 양식의 필드에 삭제되면 필드 오류가 표시됩니다.
  4. 런타임 아이콘 및 빌더 이미지는 기본적으로 선택됩니다. 빌더 이미지가 자동으로 탐지되지 않으면 빌더 이미지를 선택합니다. 필요한 경우 빌더 이미지 버전 드롭다운 목록을 사용하여 버전을 변경할 수 있습니다.
  5. 선택 사항: 애플리케이션 이름 필드에 리소스 레이블링에 사용할 애플리케이션의 고유 이름을 입력합니다.
  6. 이름 필드에 관련 리소스의 고유한 구성 요소 이름을 입력합니다.
  7. 선택 사항: 고급 옵션리소스 유형 드롭다운 목록을 사용하여 기본 리소스 유형 목록에서 다른 리소스 유형을 선택합니다.
  8. 고급 옵션 메뉴에서 애플리케이션에 대한 경로 생성을 클릭하여 배포된 애플리케이션의 공용 URL을 구성합니다.
  9. 생성을 클릭하여 애플리케이션을 배포합니다. JAR 파일이 업로드되고 있음을 알리는 알림이 표시됩니다. 알림에는 빌드 로그를 볼 수 있는 링크도 포함됩니다.
참고

빌드가 실행되는 동안 브라우저 탭을 종료하려고 하면 웹 경고가 표시됩니다.

JAR 파일이 업로드되고 애플리케이션이 배포되면 토폴로지 보기에서 애플리케이션을 볼 수 있습니다.

3.1.6. Devfile 레지스트리를 사용하여 devfile에 액세스

개발자 화면의 +추가 흐름에서 devfile을 사용하여 애플리케이션을 생성할 수 있습니다. +추가 흐름은 devfile 커뮤니티 레지스트리와 의 완전한 통합을 제공합니다. devfile은 처음부터 구성하지 않고도 개발 환경을 설명하는 이식 가능한 YAML 파일입니다. Devfile 레지스트리 를 사용하여 사전 구성된 devfile을 사용하여 애플리케이션을 생성할 수 있습니다.

절차

  1. 개발자 관점+추가개발자 카탈로그모든 서비스로 이동합니다. 개발자 카탈로그에서 사용 가능한 모든 서비스 목록이 표시됩니다.
  2. 유형 에서 Devfiles 를 클릭하여 특정 언어 또는 프레임워크를 지원하는 devfile을 찾습니다. 또는 키워드 필터를 사용하여 이름, 태그 또는 설명을 사용하여 특정 devfile을 검색할 수 있습니다.
  3. 애플리케이션을 생성하는 데 사용할 devfile을 클릭합니다. devfile 타일에는 이름, 설명, 공급자, devfile의 문서를 포함하여 devfile의 세부 정보가 표시됩니다.
  4. 생성 을 클릭하여 애플리케이션을 생성하고 토폴로지 보기에서 애플리케이션을 확인합니다.

3.1.7. 개발자 카탈로그를 사용하여 애플리케이션에 서비스 또는 구성 요소 추가

개발자 카탈로그를 사용하여 Operator 지원 서비스를 기반으로 애플리케이션 및 서비스(예: 데이터베이스, 빌더 이미지, Helm 차트)를 배포합니다. 개발자 카탈로그에는 프로젝트에 추가할 수 있는 애플리케이션 구성 요소, 서비스, 이벤트 소스 또는 source-to-image 빌더 컬렉션이 포함되어 있습니다. 클러스터 관리자는 카탈로그에서 사용 가능한 내용을 사용자 지정할 수 있습니다.

절차

  1. 개발자 화면에서 +추가 보기로 이동하여 개발자 카탈로그 타일에서 모든 서비스를 클릭하여 개발자 카탈로그에서 사용 가능한 모든 서비스를 확인합니다.
  2. 모든 서비스 아래에서 프로젝트에 추가해야 하는 서비스 종류 또는 구성 요소를 선택합니다. 이 예제에서는 데이터베이스를 선택하여 모든 데이터베이스 서비스를 나열하고 MariaDB를 클릭하여 서비스 세부 정보를 확인합니다.
  3. 템플릿 인스턴스화를 클릭하여 MariaDB 서비스 세부 정보가 자동으로 채워진 템플릿을 확인한 다음 생성을 클릭하여 토폴로지 보기에서 MariaDB 서비스를 생성하고 확인합니다.

    그림 3.1. 토폴로지의 MariaDB

    odc devcatalog 토폴로지

3.1.8. 추가 리소스

  • OpenShift Serverless의 Knative 라우팅 설정에 대한 자세한 내용은 라우팅 을 참조하십시오.
  • OpenShift Serverless의 도메인 매핑 설정에 대한 자세한 내용은 Knative 서비스의 사용자 정의 도메인 구성을 참조하십시오.
  • OpenShift Serverless의 Knative 자동 스케일링 설정에 대한 자세한 내용은 자동 스케일링을 참조하십시오.
  • 프로젝트에 새 사용자를 추가하는 방법에 대한 자세한 내용은 프로젝트 작업을 참조하십시오.
  • Helm 차트 리포지터리 생성에 대한 자세한 내용은 Helm 차트 리포지터리 생성 을 참조하십시오.

3.2. 설치된 Operator에서 애플리케이션 생성

Operator는 Kubernetes 애플리케이션을 패키징, 배포 및 관리하는 방법입니다. 클러스터 관리자가 설치한 Operator를 사용하여 OpenShift Container Platform에서 애플리케이션을 생성할 수 있습니다.

이 가이드에서는 개발자에게 OpenShift Container Platform 웹 콘솔을 사용하여 설치된 Operator에서 애플리케이션을 생성하는 예제를 보여줍니다.

추가 리소스

  • Operator 작동 방식 및 Operator Lifecycle Manager가 OpenShift Container Platform에 통합된 방법에 대한 자세한 내용은 Operator 가이드를 참조하십시오.

3.2.1. Operator를 사용하여 etcd 클러스터 생성

이 절차에서는 OLM(Operator Lifecycle Manager)에서 관리하는 etcd Operator를 사용하여 새 etcd 클러스터를 생성하는 과정을 안내합니다.

사전 요구 사항

  • OpenShift Container Platform 4.13 클러스터에 액세스할 수 있습니다.
  • 관리자가 클러스터 수준에 etcd Operator를 이미 설치했습니다.

프로세스

  1. 이 절차를 위해 OpenShift Container Platform 웹 콘솔에 새 프로젝트를 생성합니다. 이 예제에서는 my-etcd라는 프로젝트를 사용합니다.
  2. Operator → 설치된 Operator 페이지로 이동합니다. 이 페이지에는 클러스터 관리자가 클러스터에 설치하여 사용할 수 있는 Operator가 CSV(클러스터 서비스 버전) 목록으로 표시됩니다. CSV는 Operator에서 제공하는 소프트웨어를 시작하고 관리하는 데 사용됩니다.

    작은 정보

    다음을 사용하여 CLI에서 이 목록을 가져올 수 있습니다.

    $ oc get csv
  3. 자세한 내용과 사용 가능한 작업을 확인하려면 설치된 Operator 페이지에서 etcd Operator를 클릭합니다.

    이 Operator에서는 제공된 API 아래에 표시된 것과 같이 etcd 클러스터(EtcdCluster 리소스)용 하나를 포함하여 새로운 리소스 유형 세 가지를 사용할 수 있습니다. 이러한 오브젝트는 내장된 네이티브 Kubernetes 오브젝트(예: Deployment 또는 ReplicaSet)와 비슷하게 작동하지만 etcd 관리와 관련된 논리가 포함됩니다.

  4. 새 etcd 클러스터를 생성합니다.

    1. etcd 클러스터 API 상자에서 인스턴스 생성을 클릭합니다.
    2. 다음 페이지에서는 클러스터 크기와 같은 EtcdCluster 오브젝트의 최소 시작 템플릿을 수정할 수 있습니다. 지금은 생성을 클릭하여 종료하십시오. 그러면 Operator에서 새 etcd 클러스터의 Pod, 서비스 및 기타 구성 요소를 가동합니다.
  5. 예제 etcd 클러스터를 클릭한 다음 리소스 탭을 클릭하여 Operator에 의해 자동으로 생성 및 구성된 여러 리소스가 프로젝트에 포함되어 있는지 확인합니다.

    프로젝트의 다른 Pod에서 데이터베이스에 액세스할 수 있도록 Kubernetes 서비스가 생성되었는지 확인합니다.

  6. 지정된 프로젝트에서 edit 역할을 가진 모든 사용자는 클라우드 서비스와 마찬가지로 셀프 서비스 방식으로 프로젝트에 이미 생성된 Operator에서 관리하는 애플리케이션 인스턴스(이 예제의 etcd 클러스터)를 생성, 관리, 삭제할 수 있습니다. 이 기능을 사용하여 추가 사용자를 활성화하려면 프로젝트 관리자가 다음 명령을 사용하여 역할을 추가하면 됩니다.

    $ oc policy add-role-to-user edit <user> -n <target_project>

이제 Pod가 비정상적인 상태가 되거나 클러스터의 다른 노드로 마이그레이션되면 오류에 반응하고 데이터를 재조정할 etcd 클러스터가 생성되었습니다. 가장 중요한 점은 적절한 액세스 권한이 있는 클러스터 관리자 또는 개발자가 애플리케이션과 함께 데이터베이스를 쉽게 사용할 수 있다는 점입니다.

3.3. CLI를 사용하여 애플리케이션 생성

OpenShift Container Platform CLI를 사용하여 소스 또는 바이너리 코드, 이미지, 템플릿이 포함된 구성 요소에서 OpenShift Container Platform 애플리케이션을 생성할 수 있습니다.

new-app으로 생성되는 오브젝트 세트는 입력을 통해 전달되는 아티팩트(소스 리포지토리, 이미지 또는 템플릿)에 따라 다릅니다.

3.3.1. 소스 코드에서 애플리케이션 생성

new-app 명령을 사용하면 로컬 또는 원격 Git 리포지토리의 소스 코드에서 애플리케이션을 생성할 수 있습니다.

new-app 명령은 소스 코드에서 자체적으로 새 애플리케이션 이미지를 생성하는 빌드 구성을 생성합니다. 또한 new-app 명령은 일반적으로 새 이미지를 배포할 Deployment 오브젝트와 이미지를 실행하는 배포에 부하 분산 액세스를 제공하는 서비스를 생성합니다.

OpenShift Container Platform은 파이프라인, 소스 또는 docker 빌드 전략을 사용할지 여부를 자동으로 탐지하고 소스 빌드의 경우 적절한 언어 빌더 이미지를 탐지합니다.

3.3.1.1. 로컬

로컬 디렉터리의 Git 리포지토리에서 애플리케이션을 생성하려면 다음을 실행합니다.

$ oc new-app /<path to source code>
참고

로컬 Git 리포지토리를 사용하는 경우 리포지토리에 OpenShift Container Platform 클러스터에서 액세스할 수 있는 URL을 가리키는 origin이라는 원격이 있어야 합니다. 확인되는 원격이 없는 경우 new-app 명령을 실행하면 바이너리 빌드가 생성됩니다.

3.3.1.2. 원격

원격 Git 리포지토리에서 애플리케이션을 생성하려면 다음을 실행합니다.

$ oc new-app https://github.com/sclorg/cakephp-ex

프라이빗 원격 Git 리포지토리에서 애플리케이션을 생성하려면 다음을 실행합니다.

$ oc new-app https://github.com/youruser/yourprivaterepo --source-secret=yoursecret
참고

프라이빗 원격 Git 리포지토리를 사용하는 경우 --source-secret 플래그를 사용하면 빌드 구성에 삽입할 기존 소스 복제 시크릿을 지정하여 리포지토리에 액세스할 수 있습니다.

--context-dir 플래그를 지정하여 소스 코드 리포지토리의 하위 디렉터리를 사용할 수 있습니다. 원격 Git 리포지토리 및 컨텍스트 하위 디렉터리에서 애플리케이션을 생성하려면 다음을 실행합니다.

$ oc new-app https://github.com/sclorg/s2i-ruby-container.git \
    --context-dir=2.0/test/puma-test-app

또한 원격 URL을 지정하면 URL 끝에 #<branch_name>을 추가하여 사용할 Git 분기를 지정할 수 있습니다.

$ oc new-app https://github.com/openshift/ruby-hello-world.git#beta4
3.3.1.3. 빌드 전략 탐지

OpenShift Container Platform은 특정 파일을 탐지하여 사용할 빌드 전략을 자동으로 결정합니다.

  • 새 애플리케이션을 생성할 때 Jenkins 파일이 소스 리포지토리의 루트 또는 지정된 컨텍스트 디렉터리에 있는 경우 OpenShift Container Platform에서는 파이프라인 빌드 전략을 생성합니다.

    참고

    파이프라인 빌드 전략은 더 이상 사용되지 않습니다. 대신 Red Hat OpenShift Pipelines 사용을 고려하십시오.

  • 새 애플리케이션을 생성할 때 Dockerfile이 소스 리포지토리의 루트 또는 지정된 컨텍스트 디렉터리에 있는 경우 OpenShift Container Platform은 Docker 빌드 전략을 생성합니다.
  • Jenkins 파일이나 Dockerfile이 감지되지 않으면 OpenShift Container Platform에서 소스 빌드 전략을 생성합니다.

--strategy 플래그를 docker,pipeline 또는 source 로 설정하여 자동 감지된 빌드 전략을 재정의합니다.

$ oc new-app /home/user/code/myapp --strategy=docker
참고

oc 명령을 실행하려면 빌드 소스가 포함된 파일이 원격 Git 리포지토리에 제공되어야 합니다. 모든 소스 빌드에 git remote -v를 사용해야 합니다.

3.3.1.4. 언어 탐지

소스 빌드 전략을 사용하는 경우 new-app은 리포지토리의 루트 또는 지정된 컨텍스트 디렉터리에 특정 파일이 있는지에 따라 사용할 언어 빌더를 결정합니다.

표 3.1. new-app에서 탐지하는 언어
언어파일

dotnet

project.json, *.csproj

jee

pom.xml

nodejs

app.json, package.json

perl

cpanfile, index.pl

php

composer.json, index.php

python

requirements.txt, setup.py

ruby

Gemfile, Rakefile, config.ru

scala

build.sbt

golang

Godeps, main.go

언어를 탐지한 후 new-app은 OpenShift Container Platform 서버에서 탐지한 언어와 일치하는 supports 주석이 있는 이미지 스트림 태그 또는 탐지된 언어의 이름과 일치하는 이미지 스트림을 검색합니다. 일치 항목이 없는 경우 new-appDocker Hub 레지스트리에서 이름을 기반으로 탐지된 언어와 일치하는 이미지를 검색합니다.

이미지, 이미지 스트림 또는 컨테이너 사양 중 하나, 리포지토리를 구분자 ~를 사용하여 지정하면 빌더에서 특정 소스 리포지토리에 사용하는 이미지를 재정의할 수 있습니다. 이 작업이 완료되면 빌드 전략 탐지 및 언어 탐지가 수행되지 않습니다.

예를 들어 원격 리포지토리의 소스에 myproject/my-ruby 이미지 스트림을 사용하려면 다음을 실행합니다.

$ oc new-app myproject/my-ruby~https://github.com/openshift/ruby-hello-world.git

로컬 리포지토리의 소스에 openshift/ruby-20-centos7:latest 컨테이너 이미지 스트림을 사용하려면 다음을 실행합니다.

$ oc new-app openshift/ruby-20-centos7:latest~/home/user/code/my-ruby-app
참고

언어 탐지 기능에는 리포지토리를 복제하고 검사할 수 있도록 Git 클라이언트를 로컬에 설치해야 합니다. Git을 사용할 수 없는 경우 <image>~<repository> 구문으로 리포지토리에 사용할 빌더 이미지를 지정하여 언어 탐지 단계가 수행되지 않도록 수 있습니다.

-i <image> <repository> 호출을 실행하려면 new-app에서 아티팩트 유형이 무엇인지 확인하기 위해 repository를 복제해야 하므로 Git을 사용할 수 없는 경우 이 명령이 실패합니다.

-i <image> --code <repository> 호출을 실행하려면 image를 소스 코드의 빌더로 사용해야 하는지 아니면 데이터베이스 이미지의 경우와 같이 별도로 배포해야 하는지 확인하기 위해 new-app에서 repository를 복제해야 합니다.

3.3.2. 이미지에서 애플리케이션 생성

기존 이미지에서 애플리케이션을 배포할 수 있습니다. 이미지는 OpenShift Container Platform 서버의 이미지 스트림, 특정 레지스트리의 이미지 또는 로컬 Docker 서버의 이미지에서 가져올 수 있습니다.

new-app 명령은 전달된 인수에 지정된 이미지 유형을 확인합니다. 그러나 컨테이너 이미지에는 --docker-image 인수를, 이미지 스트림에는 -i|--image-stream 인수를 사용하여 new-app에 이미지 유형을 명시적으로 표시할 수 있습니다.

참고

로컬 Docker 리포지토리에서 이미지를 지정하는 경우 OpenShift Container Platform 클러스터 노드에서 동일한 이미지를 사용할 수 있는지 확인해야 합니다.

3.3.2.1. Docker Hub MySQL 이미지

Docker Hub MySQL 이미지에서 애플리케이션을 생성합니다. 예를 들면 다음과 같습니다.

$ oc new-app mysql
3.3.2.2. 프라이빗 레지스트리의 이미지

프라이빗 레지스트리의 이미지를 사용하여 애플리케이션을 생성하고 전체 컨테이너 이미지 사양을 지정합니다.

$ oc new-app myregistry:5000/example/myimage
3.3.2.3. 기존 이미지 스트림 및 선택적 이미지 스트림 태그

기존 이미지 스트림 및 선택적 이미지 스트림 태그에서 애플리케이션을 생성합니다.

$ oc new-app my-stream:v1

3.3.3. 템플릿에서 애플리케이션 생성

템플릿 이름을 인수로 지정하여 이전에 저장된 템플릿 또는 템플릿 파일에서 애플리케이션을 생성할 수 있습니다. 예를 들어 샘플 애플리케이션 템플릿을 저장하고 이 템플릿을 사용하여 애플리케이션을 생성할 수 있습니다.

현재 프로젝트의 템플릿 라이브러리에 애플리케이션 템플릿을 업로드합니다. 다음 예제에서는 examples/sample-app/application-template-stibuild.json이라는 파일에서 애플리케이션 템플릿을 업로드합니다.

$ oc create -f examples/sample-app/application-template-stibuild.json

그런 다음 애플리케이션 템플릿을 참조하여 새 애플리케이션을 생성합니다. 이 예에서 템플릿 이름은 ruby-helloworld-sample입니다.

$ oc new-app ruby-helloworld-sample

OpenShift Container Platform에 먼저 저장하지 않고 로컬 파일 시스템에서 템플릿 파일을 참조하여 새 애플리케이션을 생성하려면 -f|--file 인수를 사용하십시오. 예를 들면 다음과 같습니다.

$ oc new-app -f examples/sample-app/application-template-stibuild.json
3.3.3.1. 템플릿 매개변수

템플릿을 기반으로 애플리케이션을 생성할 때 -p|--param 인수를 사용하여 템플릿에 정의된 매개변수 값을 설정합니다.

$ oc new-app ruby-helloworld-sample \
    -p ADMIN_USERNAME=admin -p ADMIN_PASSWORD=mypassword

템플릿을 인스턴스화할 때 해당 매개변수를 파일에 저장한 다음 해당 파일을 --param-file과 함께 사용할 수 있습니다. 표준 입력에서 매개변수를 읽으려면 --param-file=-을 사용합니다. 다음은 helloworld.params라는 예제 파일입니다.

ADMIN_USERNAME=admin
ADMIN_PASSWORD=mypassword

템플릿을 인스턴스화할 때 파일에서 매개변수를 참조합니다.

$ oc new-app ruby-helloworld-sample --param-file=helloworld.params

3.3.4. 애플리케이션 생성 수정

new-app 명령은 생성된 애플리케이션을 빌드, 배포, 실행하는 OpenShift Container Platform 오브젝트를 생성합니다. 일반적으로 이러한 오브젝트는 현재 프로젝트에서 생성되고 입력 소스 리포지토리 또는 입력 이미지에서 파생된 이름이 할당됩니다. 그러나 new-app을 사용하면 이 동작을 수정할 수 있습니다.

표 3.2. new-app 출력 오브젝트
개체설명

BuildConfig

명령줄에 지정된 각 소스 리포지토리에 대해 BuildConfig 오브젝트가 생성됩니다. BuildConfig 오브젝트는 사용할 전략, 소스 위치, 빌드 출력 위치를 지정합니다.

ImageStreams

BuildConfig 오브젝트의 경우 일반적으로 두 개의 이미지 스트림이 생성됩니다. 하나는 입력 이미지를 나타냅니다. 소스 빌드에서 이 이미지는 빌더 이미지입니다. Docker 빌드에서는 출처 이미지에 해당합니다. 두 번째 이미지는 출력 이미지를 나타냅니다. 컨테이너 이미지가 new-app에 입력으로 지정되면 해당 이미지에도 이미지 스트림이 생성됩니다.

DeploymentConfig

DeploymentConfig 오브젝트는 빌드 출력 또는 지정된 이미지를 배포하기 위해 생성됩니다. new-app 명령은 결과 DeploymentConfig 오브젝트에 포함되어 있는 컨테이너에 지정된 모든 Docker 볼륨에 대해 emptyDir 볼륨을 생성합니다.

Service

new-app 명령은 입력 이미지에서 노출된 포트를 탐지합니다. 가장 낮은 숫자의 노출된 포트를 사용하여 해당 포트를 노출하는 서비스를 생성합니다. 다른 포트를 공개하려면 new-app을 완료한 후 oc expose 명령을 사용하여 추가 서비스를 생성하기만 하면 됩니다.

기타

다른 오브젝트는 템플릿을 인스턴스화할 때 템플릿에 따라 생성할 수 있습니다.

3.3.4.1. 환경 변수 지정

템플릿, 소스 또는 이미지에서 애플리케이션을 생성할 때 -e|--env 인수를 사용하여 런타임 시 환경 변수를 애플리케이션 컨테이너에 전달할 수 있습니다.

$ oc new-app openshift/postgresql-92-centos7 \
    -e POSTGRESQL_USER=user \
    -e POSTGRESQL_DATABASE=db \
    -e POSTGRESQL_PASSWORD=password

이 변수는 --env-file 인수를 사용하여 파일에서 읽을 수도 있습니다. 다음은 postgresql.env라는 예제 파일입니다.

POSTGRESQL_USER=user
POSTGRESQL_DATABASE=db
POSTGRESQL_PASSWORD=password

파일에서 변수를 읽습니다.

$ oc new-app openshift/postgresql-92-centos7 --env-file=postgresql.env

또한 --env-file=-을 사용하여 환경 변수를 표준 입력에 제공할 수 있습니다.

$ cat postgresql.env | oc new-app openshift/postgresql-92-centos7 --env-file=-
참고

new-app 처리의 일부로 생성된 모든 BuildConfig 오브젝트는 -e|--env 또는 --env-file 인수로 전달되는 환경 변수를 통해 업데이트되지 않습니다.

3.3.4.2. 빌드 환경 변수 지정

템플릿, 소스 또는 이미지에서 애플리케이션을 생성할 때 --build-env 인수를 사용하여 런타임 시 환경 변수를 빌드 컨테이너에 전달할 수 있습니다.

$ oc new-app openshift/ruby-23-centos7 \
    --build-env HTTP_PROXY=http://myproxy.net:1337/ \
    --build-env GEM_HOME=~/.gem

이 변수는 --build-env-file 인수를 사용하여 파일에서 읽을 수도 있습니다. 다음은 ruby.env라는 예제 파일입니다.

HTTP_PROXY=http://myproxy.net:1337/
GEM_HOME=~/.gem

파일에서 변수를 읽습니다.

$ oc new-app openshift/ruby-23-centos7 --build-env-file=ruby.env

또한 --build-env-file=-을 사용하여 환경 변수를 표준 입력에 제공할 수 있습니다.

$ cat ruby.env | oc new-app openshift/ruby-23-centos7 --build-env-file=-
3.3.4.3. 라벨 지정

소스, 이미지 또는 템플릿에서 애플리케이션을 생성할 때는 -l|--label 인수를 사용하여 생성된 오브젝트에 라벨을 추가할 수 있습니다. 라벨을 사용하면 애플리케이션과 관련된 오브젝트를 전체적으로 선택, 구성, 삭제할 수 있습니다.

$ oc new-app https://github.com/openshift/ruby-hello-world -l name=hello-world
3.3.4.4. 생성하지 않고 출력 보기

new-app 명령 실행의 시험 실행을 보려면 -o|--output 인수를 yaml 또는 json 값과 함께 사용하면 됩니다. 그런 다음 출력을 사용하여 생성된 오브젝트를 미리 보거나 편집할 수 있는 파일로 리디렉션할 수 있습니다. 만족하는 경우 oc create를 사용하여 OpenShift Container Platform 오브젝트를 생성할 수 있습니다.

new-app 아티팩트를 파일에 출력하려면 다음을 실행합니다.

$ oc new-app https://github.com/openshift/ruby-hello-world \
    -o yaml > myapp.yaml

파일을 편집합니다.

$ vi myapp.yaml

파일을 참조하여 새 애플리케이션을 생성합니다.

$ oc create -f myapp.yaml
3.3.4.5. 다양한 이름으로 오브젝트 생성

new-app으로 생성한 오브젝트는 일반적으로 소스 리포지토리 또는 해당 오브젝트를 생성하는 데 사용된 이미지의 이름을 따서 이름이 지정됩니다. 명령에 --name 플래그를 추가하여 생성한 오브젝트의 이름을 설정할 수 있습니다.

$ oc new-app https://github.com/openshift/ruby-hello-world --name=myapp
3.3.4.6. 다른 프로젝트에서 오브젝트 생성

일반적으로 new-app은 현재 프로젝트에서 오브젝트를 생성합니다. 그러나 -n|--namespace 인수를 사용하면 다른 프로젝트에서 오브젝트를 생성할 수 있습니다.

$ oc new-app https://github.com/openshift/ruby-hello-world -n myproject
3.3.4.7. 여러 오브젝트 생성

new-app 명령을 사용하면 new-app에 다양한 매개변수를 지정하는 애플리케이션을 여러 개 생성할 수 있습니다. 명령 줄에서 지정된 라벨은 단일 명령으로 생성된 모든 개체에 적용됩니다. 환경 변수는 소스 또는 이미지에서 생성한 모든 구성 요소에 적용됩니다.

소스 리포지토리 및 Docker Hub 이미지에서 애플리케이션을 생성하려면 다음을 실행합니다.

$ oc new-app https://github.com/openshift/ruby-hello-world mysql
참고

소스 코드 리포지토리와 빌더 이미지가 별도의 인수로 지정되면 new-app에서 빌더 이미지를 소스 코드 저장소의 빌더로 사용합니다. 이를 원하지 않는 경우 ~ 구분자를 사용하여 소스에 필요한 빌더 이미지를 지정합니다.

3.3.4.8. 단일 Pod에서 이미지 및 소스 그룹화

new-app 명령을 사용하면 단일 Pod에 여러 이미지를 함께 배포할 수 있습니다. 함께 그룹화할 이미지를 지정하려면 + 구분자를 사용합니다. --group 명령줄 인수를 사용하여 함께 그룹화해야 하는 이미지를 지정할 수도 있습니다. 소스 리포지토리에서 빌드한 이미지를 기타 이미지와 함께 그룹화하려면 그룹에 해당 빌더 이미지를 지정합니다.

$ oc new-app ruby+mysql

소스에서 빌드한 이미지를 외부 이미지와 함께 배포하려면 다음을 실행합니다.

$ oc new-app \
    ruby~https://github.com/openshift/ruby-hello-world \
    mysql \
    --group=ruby+mysql
3.3.4.9. 이미지, 템플릿 및 기타 입력 검색

oc new-app 명령에 대한 이미지, 템플릿 및 기타 입력을 검색하려면 --search--list플래그를 추가합니다. 예를 들어 PHP를 포함하는 모든 이미지 또는 템플릿을 찾으려면 다음을 실행합니다.

$ oc new-app --search php

4장. 토폴로지 보기를 사용하여 애플리케이션 구성 보기

웹 콘솔의 개발자 화면에 있는 토폴로지 보기에는 프로젝트 내의 모든 애플리케이션과 해당 빌드 상태, 애플리케이션에 연결된 구성 요소 및 서비스가 그래픽으로 표시되어 있습니다.

4.1. 사전 요구 사항

토폴로지 보기에서 애플리케이션을 확인하고 애플리케이션과 상호 작용하려면 다음을 수행합니다.

4.2. 애플리케이션의 토폴로지 보기

개발자 화면의 왼쪽 탐색 패널을 사용하여 토폴로지 보기로 이동할 수 있습니다. 애플리케이션을 배포하면 그래프 보기가 자동으로 표시됩니다. 여기에서 애플리케이션 Pod의 상태를 확인하고 공개 URL에서 애플리케이션에 빠르게 액세스한 후 소스 코드에 액세스하여 수정하고 마지막 빌드의 상태를 확인할 수 있습니다. 확대 및 축소하여 특정 애플리케이션에 대한 세부 정보를 확인할 수 있습니다.

토폴로지 보기에서는 목록 보기를 사용하여 애플리케이션을 모니터링할 수 있는 옵션을 제공합니다. 목록 보기 아이콘( odc list view icon )을 사용하여 모든 애플리케이션 목록을 확인하고 그래프 보기 아이콘( odc topology view icon )을 사용하여 그래프 보기로 다시 전환합니다.

다음을 사용하여 필요에 따라 보기를 사용자 지정할 수 있습니다.

  • 필요한 구성 요소를 찾으려면 이름으로 찾기 필드를 사용합니다. 검색 결과가 표시 영역 외부에 표시될 수 있습니다. 왼쪽 아래에 있는 툴바에서 화면에 맞추기를 클릭하여 모든 구성 요소를 표시하도록 토폴로지 보기의 크기를 조정합니다.
  • 다양한 애플리케이션 그룹화에 대한 토폴로지 보기를 구성하려면 표시 옵션 드롭다운 목록을 사용합니다. 해당 옵션은 프로젝트에 배포된 구성 요소 유형에 따라 제공됩니다.

    • 그룹 확장

      • 가상 머신: 가상 머신을 표시하거나 숨기도록 전환합니다.
      • 애플리케이션 그룹화: 애플리케이션 그룹을 애플리케이션 그룹 개요 및 연결된 알림이 포함된 카드로 축소하려면 지웁니다.
      • Helm 릴리스: Helm 릴리스로 배포된 구성 요소를 지정된 릴리스의 개요가 포함된 카드로 축소하려면 지웁니다.
      • Knative 서비스: Knative 서비스 구성 요소를 지정된 구성 요소의 개요가 포함된 카드로 축소하려면 지웁니다.
      • Operator 그룹화: Operator와 함께 배포한 구성 요소를 지정된 그룹의 개요가 포함된 카드로 축소하려면 지웁니다.
    • Pod 수 또는 라벨에 따라 표시

      • Pod 수: 구성 요소 아이콘에 구성 요소의 Pod 수를 표시하려면 선택합니다.
      • 라벨: 구성 요소 라벨을 표시하거나 숨기려면 전환합니다.

토폴로지 보기에서는 ZIP 파일 형식으로 애플리케이션을 다운로드할 수 있는 내보내기 애플리케이션 옵션도 제공합니다. 그런 다음 다운로드한 애플리케이션을 다른 프로젝트 또는 클러스터로 가져올 수 있습니다. 자세한 내용은 추가 리소스 섹션 의 다른 프로젝트 또는 클러스터로 애플리케이션 내보내기 를 참조하십시오.

4.3. 애플리케이션 및 구성 요소와 상호 작용

웹 콘솔의 개발자 화면에 있는 토폴로지 보기에서 그래프 보기에는 애플리케이션 및 구성 요소와 상호 작용할 수 있는 다음과 같은 옵션이 있습니다.

  • 공개 URL의 경로에 의해 노출되는 애플리케이션을 확인하려면 URL 열기 ( odc open url )를 클릭합니다.
  • 소스 코드에 액세스하여 수정하려면 소스 코드 편집을 클릭합니다.

    참고

    이 기능은 Git에서, 카탈로그에서, Dockerfile에서 옵션을 사용하여 애플리케이션을 생성할 때만 사용할 수 있습니다.

  • 최신 빌드의 이름과 해당 상태를 확인하려면 Pod의 왼쪽 아래 아이콘 위에 커서를 올려 놓습니다. 애플리케이션 빌드 상태는 신규 ( odc build new ), 보류 중( odc build pending ), 실행 ( odc build running ), 완료됨 ( odc build completed ), 실패 ( odc build failed odc build canceled ), 취소됨 ()으로 표시됩니다.
  • Pod의 상태 또는 단계는 다음과 같이 다양한 색상 및 툴팁으로 표시됩니다.

    • 실행 ( odc pod running ): Pod가 노드에 바인딩되고 모든 컨테이너가 생성됩니다. 하나 이상의 컨테이너가 계속 실행 중이거나 시작 또는 다시 시작하는 중입니다.
    • 준비되지 않음 ( odc pod not ready ): 여러 컨테이너를 실행하는 Pod이며 일부 컨테이너가 준비되지 않았습니다.
    • 경고( odc pod warning ): Pod의 컨테이너가 종료 중이지만 종료에 실패했습니다. 일부 컨테이너는 다른 상태일 수 있습니다.
    • 실패( odc pod failed ): Pod의 모든 컨테이너가 종료되었지만 하나 이상의 컨테이너가 실패로 종료되었습니다. 즉 컨테이너는 0이 아닌 상태로 종료되었거나 시스템에 의해 종료되었습니다.
    • 보류 중( odc pod pending ): Pod는 Kubernetes 클러스터에서 허용되지만 하나 이상의 컨테이너가 설정 및 실행할 준비가 되어 있지 않습니다. 여기에는 Pod가 네트워크를 통해 컨테이너 이미지를 다운로드하는 데 소요되는 시간뿐만 아니라 Pod를 예약 대기하는 시간이 포함됩니다.
    • 성공( odc pod succeeded ): Pod의 모든 컨테이너가 성공적으로 종료되고 재시작되지 않습니다.
    • 종료( odc pod terminating ): Pod가 삭제되면 일부 kubectl 명령에 의해 종료됨 으로 표시됩니다. 종료 중 상태는 Pod 단계 중 하나가 아닙니다. Pod에는 정상 종료 기간이 부여되며 기본값은 30초입니다.
    • 알 수 없음( odc pod unknown ): Pod 상태를 가져올 수 없습니다. 일반적으로 이 단계는 Pod가 실행되어야 하는 노드와 통신하는 동안 오류로 인해 발생합니다.
  • 애플리케이션을 생성하고 이미지를 배포하면 해당 상태가 보류 중으로 표시됩니다. 애플리케이션을 빌드한 후에는 실행 중으로 표시됩니다.

    그림 4.1. 애플리케이션 토폴로지

    odc application topology

    애플리케이션 리소스 이름에는 다음과 같이 다양한 유형의 리소스 오브젝트에 대한 표시가 추가됩니다.

    • CJ: CronJob
    • D: Deployment
    • DC: DeploymentConfig
    • DS: DaemonSet
    • J: Job
    • P: Pod
    • SS: StatefulSet
    • odc serverless app (Knative): 서버리스 애플리케이션

      참고

      서버리스 애플리케이션은 그래프 보기에 로드 및 표시되는 데 시간이 걸립니다. 서버리스 애플리케이션을 배포할 때는 먼저 서비스 리소스를 생성한 다음 리버전을 생성합니다. 그런 다음 개정 버전이 배포되고 그래프 보기에 표시됩니다. 이 작업이 유일한 워크로드인 경우 추가 페이지로 리디렉션될 수 있습니다. 리버전이 배포되면 그래프 보기에 서버리스 애플리케이션이 표시됩니다.

4.4. 애플리케이션 Pod 스케일링 및 빌드와 경로 확인

토폴로지 보기에는 개요 패널에 배포된 구성 요소의 세부 정보가 있습니다. 개요세부 정보 탭을 사용하여 다음과 같이 애플리케이션 Pod를 스케일링하고 빌드 상태, 서비스 및 경로를 확인할 수 있습니다.

  • 구성 요소 노드를 클릭하면 오른쪽에 개요 패널이 표시됩니다. 세부 정보 탭을 사용하여 다음을 수행합니다.

    • 위쪽 및 아래쪽 화살표를 사용하여 Pod 수를 스케일링하여 애플리케이션 인스턴스 수를 수동으로 늘리거나 줄입니다. 서버리스 애플리케이션의 경우 유휴 상태에서는 Pod가 자동으로 0으로 축소되고 채널 트래픽에 따라 확장됩니다.
    • 애플리케이션의 라벨, 주석, 상태를 확인합니다.
  • 다음을 수행하려면 리소스 탭을 클릭합니다.

    • 모든 Pod 목록을 확인하고 해당 상태 및 액세스 로그를 본 후 Pod 세부 정보를 확인할 Pod를 클릭합니다.
    • 빌드, 해당 상태, 액세스 로그를 확인하고 필요한 경우 새 빌드를 시작합니다.
    • 구성 요소에서 사용하는 서비스 및 경로를 참조하십시오.

    서버리스 애플리케이션의 경우 리소스 탭에는 해당 구성 요소에 사용된 리버전, 경로, 구성 정보가 있습니다.

4.5. 기존 프로젝트에 구성 요소 추가

프로젝트에 구성 요소를 추가할 수 있습니다.

절차

  1. +추가 보기로 이동합니다.
  2. 왼쪽 탐색 창 옆에 있는 프로젝트 ( odc add to project )에 추가하거나 Ctrl+공간을누릅니다.
  3. 구성 요소를 검색하고 시작/생성/설치 버튼을 클릭하거나 Enter 를 클릭하여 프로젝트에 구성 요소를 추가하고 토폴로지 그래프 보기에서 확인합니다.

    그림 4.2. 빠른 검색을 통해 구성 요소 추가

    odc quick search

또는 토폴로지 그래프 뷰에서 구성 요소를 마우스 오른쪽 버튼으로 클릭하여 Git에서 가져오기, 컨테이너이미지,데이터베이스,카탈로그에서 Operator 백업,Helm 차트,샘플 업로드 와 같은 컨텍스트 메뉴에서 사용 가능한 옵션을 사용할 수도 있습니다.

그림 4.3. 서비스를 추가하는 컨텍스트 메뉴

odc context project

4.6. 애플리케이션 내의 여러 구성 요소 그룹화

+추가 보기를 사용하여 프로젝트에 여러 구성 요소 또는 서비스를 추가하고 토폴로지 그래프 보기를 사용하여 애플리케이션 그룹 내에서 애플리케이션 및 리소스를 그룹화할 수 있습니다.

사전 요구 사항

  • 개발자 화면을 사용하여 OpenShift Container Platform에서 최소 두 개 이상의 구성 요소를 생성하고 배포했습니다.

절차

  • 기존 애플리케이션 그룹에 서비스를 추가하려면 Shift+를 기존 애플리케이션 그룹으로 드래그합니다. 구성 요소를 드래그하고 애플리케이션 그룹에 추가하면 필요한 레이블이 구성 요소에 추가됩니다.

    그림 4.4. 애플리케이션 그룹화

    odc app grouping label

또는 다음과 같이 애플리케이션에 구성 요소를 추가할 수도 있습니다.

  1. 서비스 Pod를 클릭하여 오른쪽에 개요 패널을 확인합니다.
  2. 작업 드롭다운 메뉴를 클릭하고 애플리케이션 그룹화 편집을 선택합니다.
  3. 애플리케이션 그룹화 편집 대화 상자에서 애플리케이션 드롭다운 목록을 클릭하고 적절한 애플리케이션 그룹을 선택합니다.
  4. 저장을 클릭하여 애플리케이션 그룹에 서비스를 추가합니다.

구성 요소를 선택하고 Shift 키를 누른 상태로 애플리케이션 그룹 밖으로 드래그하면 애플리케이션 그룹에서 구성 요소를 제거할 수 있습니다.

4.7. 애플리케이션에 서비스 추가

애플리케이션에 서비스를 추가하려면 토폴로지 그래프 보기 의 컨텍스트 메뉴를 사용하여 +추가 작업을 사용합니다.

참고

컨텍스트 메뉴 외에도 사이드바를 사용하거나 애플리케이션 그룹에서 dangling 화살표를 드래그하여 서비스를 추가할 수 있습니다.

절차

  1. 토폴로지 그래프 보기에서 애플리케이션 그룹을 마우스 오른쪽 버튼으로 클릭하여 컨텍스트 메뉴를 표시합니다.

    그림 4.5. 리소스 컨텍스트 메뉴 추가

    odc context menu
  2. Add to Application 을 사용하여 Git , 컨테이너이미지,Dockerfile에서 ,Devfile 으로부터,JAR 파일 업로드,이벤트 소스,채널, 브로커와 같은 애플리케이션 그룹에 서비스를 추가하는 방법을 선택합니다.
  3. 선택한 메서드에 대한 양식을 작성하고 만들기를 클릭합니다. 예를 들어 Git 리포지토리의 소스 코드를 기반으로 서비스를 추가하려면 From Git 메서드를 선택하고 Git에서 가져오기 양식을 작성하고 만들기를 클릭합니다.

4.8. 애플리케이션에서 서비스 제거

토폴로지 그래프 보기에서 컨텍스트 메뉴를 사용하여 애플리케이션에서 서비스를 제거합니다.

절차

  1. 토폴로지 그래프 보기 의 애플리케이션 그룹에서 서비스를 마우스 오른쪽 버튼으로 클릭하여 컨텍스트 메뉴를 표시합니다.
  2. 서비스를 삭제하려면 배포 삭제 를 선택합니다.

    그림 4.6. 배포 옵션 삭제

    odc deleting deployment

4.9. 토폴로지 보기에 사용되는 라벨 및 주석

토폴로지 보기에서는 다음 라벨 및 주석을 사용합니다.

노드에 표시되는 아이콘
노드의 아이콘은 app.openshift.io/runtime 라벨과 다음으로 app.kubernetes.io/name 라벨을 사용하여 일치하는 아이콘을 찾아 정의됩니다. 이러한 일치는 사전 정의된 아이콘 세트를 사용하여 수행됩니다.
소스 코드 편집기 또는 소스에 대한 링크
app.openshift.io/vcs-uri 주석은 소스 코드 편집기에 대한 링크를 생성하는 데 사용됩니다.
노드 커넥터
app.openshift.io/connects-to 주석은 노드를 연결하는 데 사용됩니다.
앱 그룹화
app.kubernetes.io/part-of=<appname> 라벨은 애플리케이션, 서비스, 구성 요소를 그룹화하는 데 사용됩니다.

OpenShift Container Platform 애플리케이션에서 사용해야 하는 라벨 및 주석에 대한 자세한 내용은 OpenShift 애플리케이션의 라벨 및 주석에 대한 지침을 참조하십시오.

4.10. 추가 리소스

5장. 애플리케이션 내보내기

개발자는 ZIP 파일 형식으로 애플리케이션을 내보낼 수 있습니다. 요구 사항에 따라 +추가 보기에서 YAML 가져오기 옵션을 사용하여 내보낸 애플리케이션을 동일한 클러스터 또는 다른 클러스터의 다른 프로젝트로 가져옵니다. 애플리케이션을 내보내면 애플리케이션 리소스를 재사용하고 시간을 절약할 수 있습니다.

5.1. 사전 요구 사항

  • OperatorHub에서 gitops-primer Operator를 설치했습니다.

    참고

    gitops-primer Operator를 설치한 후에도 토폴로지 보기에서 내보내기 애플리케이션 옵션이 비활성화되어 있습니다.

  • 애플리케이션 내보내기를 활성화하기 위해 토폴로지 보기에 애플리케이션을 생성했습니다.

5.2. 절차

  1. 개발자 관점에서 다음 단계 중 하나를 수행합니다.

    1. +추가 보기로 이동하여 애플리케이션 이식 타일에서 애플리케이션 내보내기 를 클릭합니다.
    2. 토폴로지 보기로 이동하여 애플리케이션 내보내기 를 클릭합니다.
  2. 내보내기 애플리케이션 대화 상자에서 확인을 클릭합니다. 프로젝트의 리소스 내보내기가 시작되었는지 확인하는 알림이 열립니다.
  3. 다음 시나리오에서 수행해야 할 선택적 단계:

    • 잘못된 애플리케이션 내보내기를 시작한 경우 애플리케이션 내보내기 → 내보내기 취소 를 클릭합니다.
    • 내보내기가 이미 진행 중이고 새 내보내기를 시작하려는 경우 애플리케이션 내보내기 → 내보내기 다시 시작을 클릭합니다.
    • 애플리케이션 내보내기와 관련된 로그를 보려면 애플리케이션 내보내기로그 보기 링크를 클릭합니다.

      애플리케이션 내보내기 대화 상자
  4. 성공적인 내보내기 후 대화 상자에서 다운로드를 클릭하여 ZIP 형식의 애플리케이션 리소스를 컴퓨터에 다운로드합니다.

6장. 서비스에 애플리케이션 연결

6.1. Service Binding Operator의 릴리스 노트

Service Binding Operator는 컨트롤러 및 서비스 바인딩을 위한 CRD(사용자 정의 리소스 정의)로 구성됩니다. 워크로드 및 지원 서비스의 데이터 플레인을 관리합니다. Service Binding Controller는 서비스 지원 컨트롤 플레인에서 사용 가능한 데이터를 읽습니다. 그런 다음 ServiceBinding 리소스를 통해 지정된 규칙에 따라 이 데이터를 워크로드에 생성합니다.

Service Binding Operator를 사용하면 다음을 수행할 수 있습니다.

  • Operator 관리 지원 서비스와 함께 워크로드를 바인딩합니다.
  • 바인딩 데이터 구성을 자동화합니다.
  • 서비스 운영자에게 낮은 수준의 관리 환경을 제공하여 서비스에 대한 액세스를 프로비저닝 및 관리합니다.
  • 클러스터 환경에서 불일치를 제거하는 일관되고 선언적 서비스 바인딩 방법을 사용하여 개발 라이프사이클을 보강합니다.

Service Binding Operator의 CRD(사용자 정의 리소스 정의)는 다음 API를 지원합니다.

  • binding.operators.coreos.com API 그룹을 사용한 서비스 바인딩.
  • servicebinding.io API 그룹을 사용하는 서비스 바인딩(Spec API).

6.1.1. 지원 매트릭스

다음 표의 일부 기능은 기술 프리뷰 에 있습니다. 이러한 실험적 기능은 프로덕션용이 아닙니다.

아래 표에서 기능은 다음과 같은 상태로 표시되어 있습니다.

  • TP: 기술 프리뷰
  • GA: 상용 버전

해당 기능은 Red Hat Customer Portal의 지원 범위를 참조하십시오.

표 6.1. 지원 매트릭스
Service Binding OperatorAPI 그룹 및 지원 상태OpenShift 버전

버전

binding.operators.coreos.com

servicebinding.io

 

1.3.3

GA

GA

4.9-4.12

1.3.1

GA

GA

4.9-4.11

1.3

GA

GA

4.9-4.11

1.2

GA

GA

4.7-4.11

1.1.1

GA

TP

4.7-4.10

1.1

GA

TP

4.7-4.10

1.0.1

GA

TP

4.7-4.9

1.0

GA

TP

4.7-4.9

6.1.2. 보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 용어를 교체하기 위해 최선을 다하고 있습니다. 먼저 마스터(master), 슬레이브(slave), 블랙리스트(blacklist), 화이트리스트(whitelist) 등 네 가지 용어를 교체하고 있습니다. 이러한 변경 작업은 향후 여러 릴리스에 대해 단계적으로 구현될 예정입니다. 자세한 내용은 Red Hat CTO Chris Wright의 메시지에서 참조하십시오.

6.1.3. Service Binding Operator 1.3.3 릴리스 노트

Service Binding Operator 1.3.3은 이제 OpenShift Container Platform 4.9, 4.10, 4.11 및 4.12에서 사용할 수 있습니다.

6.1.3.1. 해결된 문제
  • 이번 업데이트 이전에는 보안 취약점 CVE-2022-41717 이 Service Binding Operator에 대해 언급되었습니다. 이번 업데이트에서는 CVE-2022-41717 오류를 수정하고 golang.org/x/net 패키지를 v0.0.0-20220906165146-f33e06e74c에서 v0.4.0으로 업데이트합니다. APPSVC-1256
  • 이번 업데이트 이전에는 다른 프로비저닝 서비스가 누락된 동안 각 리소스에 "servicebinding.io/provisioned-service: true" 주석이 설정된 경우에만 프로비저닝된 서비스가 탐지되었습니다. 이번 업데이트를 통해 "status.binding.name" 속성을 기반으로 모든 프로비저닝 서비스를 올바르게 식별합니다. APPSVC-1204

6.1.4. Service Binding Operator 1.3.1 릴리스 노트

Service Binding Operator 1.3.1은 OpenShift Container Platform 4.9, 4.10, 4.11에서 사용할 수 있습니다.

6.1.4.1. 해결된 문제
  • 이번 업데이트 이전에는 Service Binding Operator에 대해 보안 취약점 CVE-2022-32149 가 기록되었습니다. 이번 업데이트에서는 CVE-2022-32149 오류가 수정되고 golang.org/x/text 패키지를 v0.3.7에서 v0.3.8로 업데이트합니다. APPSVC-1220

6.1.5. Service Binding Operator 1.3 릴리스 정보

Service Binding Operator 1.3은 이제 OpenShift Container Platform 4.9, 4.10, 4.11에서 사용할 수 있습니다.

6.1.5.1. 제거된 기능
  • Service Binding Operator 1.3에서 리소스 사용률을 개선하기 위해 OLM(Operator Lifecycle Manager) 설명자 기능이 제거되었습니다. OLM 설명자 대신 CRD 주석을 사용하여 바인딩 데이터를 선언할 수 있습니다.

6.1.6. Service Binding Operator 1.2 릴리스 노트

Service Binding Operator 1.2는 OpenShift Container Platform 4.7, 4.8, 4.9, 4.10 및 4.11에서 사용할 수 있습니다.

6.1.6.1. 새로운 기능

이 섹션에서는 Service Binding Operator 1.2의 새로운 기능에 대해 설명합니다.

  • 선택적 플래그 값을 true 로 설정하여 Service Binding Operator를 활성화하여 주석에서 선택적 필드를 고려합니다.
  • servicebinding.io/v1beta1 리소스를 지원합니다.
  • 워크로드가 없는 상태에서 관련 바인딩 시크릿을 노출하여 바인딩 가능 서비스의 발견 가능성이 향상되었습니다.
6.1.6.2. 확인된 문제
  • 현재 OpenShift Container Platform 4.11에 Service Binding Operator를 설치할 때 Service Binding Operator의 메모리 풋프린이 예상 제한을 초과합니다. 그러나 사용량이 적으면 메모리 공간은 환경 또는 시나리오의 예상 범위 내에 유지됩니다. OpenShift Container Platform 4.10과 비교하면 평균 및 최대 메모리 풋프린트가 증가합니다. 이 문제는 이전 버전의 Service Binding Operator에서도 중요합니다. 현재 이 문제에 대한 해결방법이 없습니다. APPSVC-1200
  • 기본적으로 예상된 파일에는 0644로 설정된 권한을 가져옵니다. Service Binding Operator는 Kubernetes의 버그로 인해 특정 권한을 설정할 수 없으므로 서비스에 0600 과 같은 특정 권한이 필요한 경우 문제가 발생합니다. 이 문제를 해결하려면 프로그램 코드 또는 워크로드 리소스 내에서 실행 중인 애플리케이션의 코드를 수정하여 파일을 /tmp 디렉터리에 복사하고 적절한 권한을 설정할 수 있습니다. APPSVC-1127
  • 현재 단일 네임스페이스 설치 모드에서 Service Binding Operator를 설치하는 데 알려진 문제가 있습니다. 적절한 네임스페이스 범위의 역할 기반 액세스 제어(RBAC) 규칙이 없으면 Service Binding Operator가 자동으로 감지하여 바인딩할 수 있는 알려진 몇 가지 Operator 지원 서비스에 애플리케이션을 성공적으로 바인딩할 수 있습니다. 이 경우 다음 예와 유사한 오류 메시지가 생성됩니다.

    오류 메시지의 예

    `postgresclusters.postgres-operator.crunchydata.com "hippo" is forbidden:
            User "system:serviceaccount:my-petclinic:service-binding-operator" cannot
            get resource "postgresclusters" in API group "postgres-operator.crunchydata.com"
            in the namespace "my-petclinic"`

    해결방법 1: 모든 네임스페이스 설치 모드에서 Service Binding Operator를 설치합니다. 결과적으로 적절한 클러스터 범위 RBAC 규칙이 있으며 바인딩이 성공합니다.

    해결방법 2: 모든 네임스페이스 설치 모드에서 Service Binding Operator를 설치할 수 없는 경우 Service Binding Operator가 설치된 네임스페이스에 다음 역할 바인딩을 설치합니다.

    예: Crunchy Postgres Operator에 대한 역할 바인딩

    kind: RoleBinding
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: service-binding-crunchy-postgres-viewer
    subjects:
      - kind: ServiceAccount
        name: service-binding-operator
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: ClusterRole
      name: service-binding-crunchy-postgres-viewer-role

    APPSVC-1062

  • 사양에 따라 ClusterWorkloadResourceMapping 리소스를 변경할 때 Service Binding Operator는 이전 버전의 ClusterWorkloadResourceMapping 리소스를 사용하여 현재 예상 중인 바인딩 데이터를 제거해야 합니다. 현재 ClusterWorkloadResourceMapping 리소스를 변경할 때 Service Binding Operator는 최신 버전의 ClusterWorkloadResourceMapping 리소스를 사용하여 바인딩 데이터를 제거합니다. 결과적으로 {the servicebinding-title}은 바인딩 데이터를 잘못 제거할 수 있습니다. 해결 방법으로 다음 단계를 수행합니다.

    1. 해당 ClusterWorkloadResourceMapping 리소스를 사용하는 ServiceBinding 리소스를 삭제합니다.
    2. ClusterWorkloadResourceMapping 리소스를 수정합니다.
    3. 1단계에서 이전에 삭제한 ServiceBinding 리소스를 다시 적용합니다.

    APPSVC-1102

6.1.7. Service Binding Operator 1.1.1 릴리스 노트

Service Binding Operator 1.1.1은 OpenShift Container Platform 4.7, 4.8, 4.9 및 4.10에서 사용할 수 있습니다.

6.1.7.1. 해결된 문제
  • 이번 업데이트 이전에는 Service Binding Operator Helm 차트에 대해 보안 취약점 CVE-2021-38561 이 기록되었습니다. 이번 업데이트에서는 CVE-2021-38561 오류가 수정되고 golang.org/x/text 패키지가 v0.3.6에서 v0.3.7로 업데이트됩니다. APPSVC-1124
  • 이번 업데이트 이전에는 개발자 샌드박스 사용자에게 ClusterWorkloadResourceMapping 리소스를 읽을 수 있는 충분한 권한이 없었습니다. 결과적으로 Service Binding Operator는 모든 서비스 바인딩에 성공하지 못했습니다. 이번 업데이트를 통해 Service Binding Operator에 개발자 샌드박스 사용자를 포함하여 인증된 대상에 대한 적절한 RBAC(역할 기반 액세스 제어) 규칙이 포함됩니다. 이러한 RBAC 규칙을 통해 Service Binding Operator는 개발자 샌드박스 사용자의 ClusterWorkloadResourceMapping 리소스를 가져오고 서비스 바인딩을 성공적으로 처리할 수 있습니다. APPSVC-1135
6.1.7.2. 확인된 문제
  • 현재 단일 네임스페이스 설치 모드에서 Service Binding Operator를 설치하는 데 알려진 문제가 있습니다. 적절한 네임스페이스 범위의 역할 기반 액세스 제어(RBAC) 규칙이 없으면 Service Binding Operator가 자동으로 감지하여 바인딩할 수 있는 알려진 몇 가지 Operator 지원 서비스에 애플리케이션을 성공적으로 바인딩할 수 있습니다. 이 경우 다음 예와 유사한 오류 메시지가 생성됩니다.

    오류 메시지의 예

    `postgresclusters.postgres-operator.crunchydata.com "hippo" is forbidden:
            User "system:serviceaccount:my-petclinic:service-binding-operator" cannot
            get resource "postgresclusters" in API group "postgres-operator.crunchydata.com"
            in the namespace "my-petclinic"`

    해결방법 1: 모든 네임스페이스 설치 모드에서 Service Binding Operator를 설치합니다. 결과적으로 적절한 클러스터 범위 RBAC 규칙이 있으며 바인딩이 성공합니다.

    해결방법 2: 모든 네임스페이스 설치 모드에서 Service Binding Operator를 설치할 수 없는 경우 Service Binding Operator가 설치된 네임스페이스에 다음 역할 바인딩을 설치합니다.

    예: Crunchy Postgres Operator에 대한 역할 바인딩

    kind: RoleBinding
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: service-binding-crunchy-postgres-viewer
    subjects:
      - kind: ServiceAccount
        name: service-binding-operator
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: ClusterRole
      name: service-binding-crunchy-postgres-viewer-role

    APPSVC-1062

  • 현재 ClusterWorkloadResourceMapping 리소스를 수정할 때 Service Binding Operator가 올바른 동작을 구현하지 않습니다. 해결 방법으로 다음 단계를 수행합니다.

    1. 해당 ClusterWorkloadResourceMapping 리소스를 사용하는 ServiceBinding 리소스를 삭제합니다.
    2. ClusterWorkloadResourceMapping 리소스를 수정합니다.
    3. 1단계에서 이전에 삭제한 ServiceBinding 리소스를 다시 적용합니다.

    APPSVC-1102

6.1.8. Service Binding Operator 1.1 릴리스 노트

Service Binding Operator는 OpenShift Container Platform 4.7, 4.8, 4.9 및 4.10에서 사용할 수 있습니다.

6.1.8.1. 새로운 기능

이 섹션에서는 Service Binding Operator 1.1의 새로운 기능에 대해 설명합니다.

  • 서비스 바인딩 옵션

    • 워크로드 리소스 매핑: 보조 워크로드에 대해 바인딩 데이터를 예상해야 하는 위치를 정확하게 정의합니다.
    • 라벨 선택기를 사용하여 새 워크로드를 바인딩합니다.
6.1.8.2. 해결된 문제
  • 이번 업데이트 이전에는 라벨 선택기를 사용하여 워크로드를 선택하는 서비스 바인딩에서 지정된 라벨 선택기와 일치하는 새 워크로드에 서비스 바인딩 데이터를 프로젝트하지 않았습니다. 결과적으로 Service Binding Operator는 이러한 새 워크로드를 주기적으로 바인딩할 수 없었습니다. 이번 업데이트를 통해 이제 서비스 바인딩이 지정된 라벨 선택기와 일치하는 새 워크로드에 프로젝트 서비스 바인딩 데이터를 바인딩합니다. Service Binding Operator는 이제 이러한 새 워크로드를 찾아서 바인딩하려고 합니다. APPSVC-1083
6.1.8.3. 확인된 문제
  • 현재 단일 네임스페이스 설치 모드에서 Service Binding Operator를 설치하는 데 알려진 문제가 있습니다. 적절한 네임스페이스 범위의 역할 기반 액세스 제어(RBAC) 규칙이 없으면 Service Binding Operator가 자동으로 감지하여 바인딩할 수 있는 알려진 몇 가지 Operator 지원 서비스에 애플리케이션을 성공적으로 바인딩할 수 있습니다. 이 경우 다음 예와 유사한 오류 메시지가 생성됩니다.

    오류 메시지의 예

    `postgresclusters.postgres-operator.crunchydata.com "hippo" is forbidden:
            User "system:serviceaccount:my-petclinic:service-binding-operator" cannot
            get resource "postgresclusters" in API group "postgres-operator.crunchydata.com"
            in the namespace "my-petclinic"`

    해결방법 1: 모든 네임스페이스 설치 모드에서 Service Binding Operator를 설치합니다. 결과적으로 적절한 클러스터 범위 RBAC 규칙이 있으며 바인딩이 성공합니다.

    해결방법 2: 모든 네임스페이스 설치 모드에서 Service Binding Operator를 설치할 수 없는 경우 Service Binding Operator가 설치된 네임스페이스에 다음 역할 바인딩을 설치합니다.

    예: Crunchy Postgres Operator에 대한 역할 바인딩

    kind: RoleBinding
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: service-binding-crunchy-postgres-viewer
    subjects:
      - kind: ServiceAccount
        name: service-binding-operator
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: ClusterRole
      name: service-binding-crunchy-postgres-viewer-role

    APPSVC-1062

  • 현재 ClusterWorkloadResourceMapping 리소스를 수정할 때 Service Binding Operator가 올바른 동작을 구현하지 않습니다. 해결 방법으로 다음 단계를 수행합니다.

    1. 해당 ClusterWorkloadResourceMapping 리소스를 사용하는 ServiceBinding 리소스를 삭제합니다.
    2. ClusterWorkloadResourceMapping 리소스를 수정합니다.
    3. 1단계에서 이전에 삭제한 ServiceBinding 리소스를 다시 적용합니다.

    APPSVC-1102

6.1.9. Service Binding Operator 1.0.1의 릴리스 노트

Service Binding Operator는 OpenShift Container Platform 4.7, 4.8 및 4.9에서 사용할 수 있습니다.

Service Binding Operator 1.0.1은 다음에서 실행되는 OpenShift Container Platform 4.9 이상을 지원합니다.

  • IBM Power Systems
  • IBM Z 및 LinuxONE

Service Binding Operator 1.0.1의 CRD(사용자 정의 리소스 정의)는 다음 API를 지원합니다.

  • binding.operators.coreos.com API 그룹을 사용한 서비스 바인딩.
  • servicebinding.io API 그룹을 사용하는 서비스 바인딩(Spec API Tech Preview) 입니다.

    중요

    servicebinding.io API 그룹을 사용하는 서비스 바인딩(Spec API Tech Preview) 은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

    Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

6.1.9.1. 지원 매트릭스

이 릴리스의 일부 기능은 현재 기술 프리뷰 단계에 있습니다. 이러한 실험적 기능은 프로덕션용이 아닙니다.

기술 프리뷰 기능 지원 범위

아래 표에서 기능은 다음 상태로 표시됩니다.

  • TP: 기술 프리뷰
  • GA: 상용 버전

해당 기능은 Red Hat Customer Portal의 지원 범위를 참조하십시오.

표 6.2. 지원 매트릭스
기능Service Binding Operator 1.0.1

binding.operators.coreos.com API 그룹

GA

ServiceBinding.io API 그룹

TP

6.1.9.2. 해결된 문제
  • 이번 업데이트 이전에는 postgresql.k8s.enterpriesedb.io/v1 API의 Cluster CR(사용자 정의 리소스)의 데이터 값을 바인딩하면 CR의 .metadata.name 필드에서 호스트 바인딩 값을 수집했습니다. 수집된 바인딩 값은 잘못된 호스트 이름이며 올바른 호스트 이름은 .status.writeService 필드에서 사용할 수 있습니다. 이번 업데이트를 통해 Service Binding Operator에서 백업 서비스 CR의 바인딩 데이터 값을 노출하는 데 사용하는 주석이 수정되어 .status.writeService 필드에서 호스트 바인딩 값을 수집할 수 있습니다. Service Binding Operator는 이러한 수정된 주석을 사용하여 호스트 및 공급자 바인딩에서 올바른 호스트 이름을 프로젝트합니다. APPSVC-1040
  • 이번 업데이트 이전에는 postgres-operator.crunchydata.com/v1beta1 API의 PostgresCluster CR을 바인딩할 때 바인딩 데이터 값에 데이터베이스 인증서의 값이 포함되지 않았습니다. 이로 인해 애플리케이션이 데이터베이스에 연결되지 못했습니다. 이번 업데이트를 통해 Service Binding Operator가 백업 서비스 CR의 바인딩 데이터를 노출하는 데 사용하는 주석을 수정해도 이제 데이터베이스 인증서가 포함됩니다. Service Binding Operator는 이러한 수정된 주석을 사용하여 올바른 ca.crt,tls.crt, tls.key 인증서 파일을 예상합니다. APPSVC-1045
  • 이번 업데이트 이전에는 pxc.percona.com API의 PerconaXtraDBCluster CR(사용자 정의 리소스)을 바인딩할 때 바인딩 데이터 값에 포트데이터베이스 값이 포함되지 않았습니다. 이러한 바인딩 값과 이미 예상된 다른 바인딩 값은 애플리케이션이 데이터베이스 서비스에 성공적으로 연결하려면 필요합니다. 이번 업데이트를 통해 Service Binding Operator가 백업 서비스 CR의 바인딩 데이터 값을 노출하는 데 사용하는 주석이 추가 포트데이터베이스 바인딩 값을 프로젝트에 맞게 수정됩니다. Service Binding Operator는 이러한 수정된 주석을 사용하여 애플리케이션이 데이터베이스 서비스에 성공적으로 연결하는 데 사용할 수 있는 바인딩 값의 전체 집합을 예상합니다. APPSVC-1073
6.1.9.3. 확인된 문제
  • 현재 단일 네임스페이스 설치 모드에 Service Binding Operator를 설치할 때 적절한 네임스페이스 범위의 역할 기반 액세스 제어(RBAC) 규칙이 없으면 Service Binding Operator가 자동으로 탐지하고 바인딩할 수 있는 몇 가지 알려진 Operator 지원 서비스에 애플리케이션을 성공적으로 바인딩하지 못합니다. 또한 다음 오류 메시지가 생성됩니다.

    오류 메시지의 예

    `postgresclusters.postgres-operator.crunchydata.com "hippo" is forbidden:
            User "system:serviceaccount:my-petclinic:service-binding-operator" cannot
            get resource "postgresclusters" in API group "postgres-operator.crunchydata.com"
            in the namespace "my-petclinic"`

    해결방법 1: 모든 네임스페이스 설치 모드에서 Service Binding Operator를 설치합니다. 결과적으로 적절한 클러스터 범위 RBAC 규칙이 있으며 바인딩이 성공합니다.

    해결방법 2: 모든 네임스페이스 설치 모드에서 Service Binding Operator를 설치할 수 없는 경우 Service Binding Operator가 설치된 네임스페이스에 다음 역할 바인딩을 설치합니다.

    예: Crunchy Postgres Operator에 대한 역할 바인딩

    kind: RoleBinding
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: service-binding-crunchy-postgres-viewer
    subjects:
      - kind: ServiceAccount
        name: service-binding-operator
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: ClusterRole
      name: service-binding-crunchy-postgres-viewer-role

    APPSVC-1062

6.1.10. Service Binding Operator 1.0 릴리스 노트

Service Binding Operator는 OpenShift Container Platform 4.7, 4.8 및 4.9에서 사용할 수 있습니다.

Service Binding Operator 1.0의 CRD(사용자 정의 리소스 정의)는 다음 API를 지원합니다.

  • binding.operators.coreos.com API 그룹을 사용한 서비스 바인딩.
  • servicebinding.io API 그룹을 사용하는 서비스 바인딩(Spec API Tech Preview) 입니다.

    중요

    servicebinding.io API 그룹을 사용하는 서비스 바인딩(Spec API Tech Preview) 은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

    Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

6.1.10.1. 지원 매트릭스

이 릴리스의 일부 기능은 현재 기술 프리뷰 단계에 있습니다. 이러한 실험적 기능은 프로덕션용이 아닙니다.

기술 프리뷰 기능 지원 범위

아래 표에서 기능은 다음 상태로 표시됩니다.

  • TP: 기술 프리뷰
  • GA: 상용 버전

해당 기능은 Red Hat Customer Portal의 지원 범위를 참조하십시오.

표 6.3. 지원 매트릭스
기능Service Binding Operator 1.0

binding.operators.coreos.com API 그룹

GA

ServiceBinding.io API 그룹

TP

6.1.10.2. 새로운 기능

Service Binding Operator 1.0은 다음에서 실행되는 OpenShift Container Platform 4.9 이상을 지원합니다.

  • IBM Power Systems
  • IBM Z 및 LinuxONE

이 섹션에서는 Service Binding Operator 1.0의 새로운 기능을 강조합니다.

  • 서비스의 바인딩 데이터 노출

    • CRD, CR(사용자 정의 리소스) 또는 리소스에 있는 주석을 기반으로 합니다.
    • OLM(Operator Lifecycle Manager) 설명자에 있는 설명자를 기반으로 합니다.
    • 프로비저닝된 서비스 지원
  • 워크로드 프로젝션

    • 볼륨 마운트를 사용하여 데이터를 파일로 바인딩합니다.
    • 바인딩 데이터를 환경 변수로 예상합니다.
  • 서비스 바인딩 옵션

    • 워크로드 네임스페이스와 다른 네임스페이스에 서비스를 바인딩 백업합니다.
    • 프로젝트 바인딩 데이터를 특정 컨테이너 워크로드에 연결합니다.
    • 지원 서비스 CR이 소유한 리소스에서 바인딩 데이터를 자동으로 탐지합니다.
    • 노출된 바인딩 데이터에서 사용자 지정 바인딩 데이터를 작성합니다.
    • PodSpec 호환 워크로드 리소스 지원
  • 보안

    • 역할 기반 액세스 제어(RBAC) 지원

6.1.11. 추가 리소스

6.2. Service Binding Operator 이해

애플리케이션 개발자는 워크로드를 빌드하고 연결하기 위해 서비스를 백업하기 위한 액세스 권한이 필요합니다. 워크로드를 백업 서비스에 연결하면 각 서비스 공급자가 시크릿에 액세스하고 워크로드에서 사용할 수 있는 다른 방법을 제안하기 때문에 항상 문제가 될 수 있습니다. 또한 이러한 워크로드 및 지원 서비스의 바인딩을 수동으로 구성 및 유지 관리하면 프로세스가 번거롭고 비효율적이며 오류가 발생하기 쉽습니다.

Service Binding Operator를 사용하면 수동 프로시저로 바인딩 연결을 구성하지 않고도 애플리케이션 개발자가 Operator 관리 백업 서비스와 함께 워크로드를 쉽게 바인딩할 수 있습니다.

6.2.1. 서비스 바인딩 용어

이 섹션에는 Service Binding에 사용된 기본 용어가 요약되어 있습니다.

서비스 바인딩

워크로드에 서비스에 대한 정보를 제공하는 작업의 표현입니다. 예를 들어 Java 애플리케이션과 필요한 데이터베이스 간의 자격 증명 교환을 설정하는 작업이 있습니다.

백업 서비스

애플리케이션이 일반 운영의 일부로 네트워크를 통해 사용하는 서비스 또는 소프트웨어입니다. 예를 들어 데이터베이스, 메시지 브로커, REST 엔드 포인트가 있는 애플리케이션, 이벤트 스트림, APM(Application Performance Monitor) 또는 HSM(Hardware Security Module)이 있습니다.

워크로드(애플리케이션)

컨테이너 내에서 실행되는 모든 프로세스. 예를 들어 Spring Boot 애플리케이션, NodeJS Express 애플리케이션 또는 Ruby on Rails 애플리케이션이 있습니다.

데이터 바인딩

클러스터 내의 다른 리소스의 동작을 구성하는 데 사용하는 서비스에 대한 정보입니다. 예를 들면 인증 정보, 연결 세부 정보, 볼륨 마운트 또는 시크릿이 있습니다.

바인딩 연결

바인딩 가능한 백업 서비스 및 해당 백업 서비스가 필요한 애플리케이션과 같이 연결된 구성 요소 간 상호 작용을 설정하는 모든 연결입니다.

6.2.2. Service Binding Operator 정보

Service Binding Operator는 컨트롤러 및 서비스 바인딩을 위한 CRD(사용자 정의 리소스 정의)로 구성됩니다. 워크로드 및 지원 서비스의 데이터 플레인을 관리합니다. Service Binding Controller는 서비스 지원 컨트롤 플레인에서 사용 가능한 데이터를 읽습니다. 그런 다음 ServiceBinding 리소스를 통해 지정된 규칙에 따라 이 데이터를 워크로드에 생성합니다.

결과적으로 Service Binding Operator를 사용하면 워크로드와 바인딩 데이터를 자동으로 수집하고 공유하여 백업 서비스 또는 외부 서비스를 사용할 수 있습니다. 이 프로세스에는 백업 서비스를 바인딩할 수 있고 워크로드와 서비스를 함께 바인딩해야 합니다.

6.2.2.1. Operator 관리 백업 서비스를 바인딩할 수 있도록 설정

Operator 공급자로 서비스를 바인딩할 수 있도록 하려면 Operator에서 제공하는 서비스와 바인딩하는 데 워크로드에 필요한 바인딩 데이터를 노출해야 합니다. 지원 서비스를 관리하는 Operator의 CRD에서 바인딩 데이터를 주석 또는 설명자로 제공할 수 있습니다.

6.2.2.2. 백업 서비스와 함께 워크로드 바인딩

Service Binding Operator를 애플리케이션 개발자로 사용하면 바인딩 연결을 설정하려는 의도를 선언해야 합니다. 백업 서비스를 참조하는 ServiceBinding CR을 생성해야 합니다. 이 작업을 수행하면 Service Binding Operator가 노출된 바인딩 데이터를 워크로드에 예상합니다. Service Binding Operator는 선언된 의도를 수신하고 백업 서비스와 함께 워크로드를 바인딩합니다.

Service Binding Operator의 CRD는 다음 API를 지원합니다.

  • binding.operators.coreos.com API 그룹을 사용한 서비스 바인딩.
  • servicebinding.io API 그룹을 사용하는 서비스 바인딩(Spec API).

Service Binding Operator를 사용하면 다음을 수행할 수 있습니다.

  • 워크로드를 Operator에서 관리하는 백업 서비스에 바인딩합니다.
  • 바인딩 데이터 구성을 자동화합니다.
  • 서비스 운영자에게 서비스 액세스 프로비저닝 및 관리를 위한 저치 관리 환경을 제공합니다.
  • 클러스터 환경에서 불일치를 제거하는 일관되고 선언적 서비스 바인딩 방법으로 개발 라이프사이클을 강화합니다.

6.2.3. 주요 기능

  • 서비스의 바인딩 데이터 노출

    • CRD, CR(사용자 정의 리소스) 또는 리소스에 있는 주석을 기반으로 합니다.
  • 워크로드 프로젝션

    • 볼륨 마운트를 사용하여 데이터를 파일로 바인딩합니다.
    • 바인딩 데이터를 환경 변수로 예상합니다.
  • 서비스 바인딩 옵션

    • 워크로드 네임스페이스와 다른 네임스페이스에 서비스를 바인딩 백업합니다.
    • 프로젝트 바인딩 데이터를 특정 컨테이너 워크로드에 연결합니다.
    • 지원 서비스 CR이 소유한 리소스에서 바인딩 데이터를 자동으로 탐지합니다.
    • 노출된 바인딩 데이터에서 사용자 지정 바인딩 데이터를 작성합니다.
    • PodSpec 호환 워크로드 리소스 지원
  • 보안

    • 역할 기반 액세스 제어(RBAC) 지원

6.2.4. API 차이점

Service Binding Operator의 CRD는 다음 API를 지원합니다.

  • binding.operators.coreos.com API 그룹을 사용한 서비스 바인딩.
  • servicebinding.io API 그룹을 사용하는 서비스 바인딩(Spec API).

이 두 API 그룹 모두 유사한 기능을 가지고 있지만 완전히 동일하지는 않습니다. 다음은 이러한 API 그룹의 전체 차이점 목록입니다.

기능binding.operators.coreos.com API 그룹에서 지원servicebinding.io API 그룹에서 지원참고

프로비저닝된 서비스에 바인딩

제공됨

제공됨

해당 없음 (N/A)

직접 시크릿 프로젝션

제공됨

제공됨

해당 없음 (N/A)

파일로 바인딩

제공됨

제공됨

  • servicebinding.io API 그룹의 서비스 바인딩의 기본 동작
  • binding.operators.coreos.com API 그룹의 서비스 바인딩에 대한 옵트인 기능

환경 변수로 바인딩

제공됨

제공됨

  • binding.operators.coreos.com API 그룹의 서비스 바인딩에 대한 기본 동작입니다.
  • servicebinding.io API 그룹의 서비스 바인딩에 대한 옵트인 기능: 파일과 함께 환경 변수가 생성됩니다.

라벨 선택기를 사용하여 워크로드 선택

제공됨

제공됨

해당 없음 (N/A)

바인딩 리소스 탐지 (.spec.detectBindingResources)

제공됨

없음

servicebinding.io API 그룹에는 동등한 기능이 없습니다.

이름 지정 전략

제공됨

없음

servicebinding.io API 그룹 내에는 이름 지정 전략에서 사용하는 템플릿을 해석하는 현재 메커니즘이 없습니다.

컨테이너 경로

제공됨

부분

binding.operators.coreos.com API 그룹의 서비스 바인딩은 ServiceBinding 리소스 내에서 매핑 동작을 지정할 수 있으므로 servicebinding.io API 그룹은 워크로드에 대한 자세한 정보 없이 동등한 동작을 완전히 지원할 수 없습니다.

컨테이너 이름 필터링

없음

제공됨

binding.operators.coreos.com API 그룹에는 동등한 기능이 없습니다.

보안 경로

제공됨

없음

servicebinding.io API 그룹에는 동등한 기능이 없습니다.

대체 바인딩 소스(예: 주석의 바인딩 데이터)

제공됨

Service Binding Operator에서 허용

사양을 사용하려면 프로비저닝된 서비스 및 시크릿에서 바인딩 데이터를 가져와야 합니다. 그러나 사양을 엄격하게 읽는 경우 다른 바인딩 데이터 소스에 대한 지원이 허용됩니다. Service Binding Operator는 이 팩트를 사용하여 다양한 소스에서 바인딩 데이터를 가져올 수 있습니다(예: 주석에서 바인딩 데이터 가져오기). Service Binding Operator는 API 그룹 모두에서 이러한 소스를 지원합니다.

6.2.5. 추가 리소스

6.3. Service Binding Operator 설치

이 가이드에서는 클러스터 관리자에게 OpenShift Container Platform 클러스터에 Service Binding Operator 설치 프로세스를 안내합니다.

OpenShift Container Platform 4.7 이상에 Service Binding Operator를 설치할 수 있습니다.

사전 요구 사항
  • cluster-admin 권한이 있는 계정을 사용하여 OpenShift Container Platform 클러스터에 액세스할 수 있습니다.
  • 클러스터에 Marketplace 기능이 활성화되어 있거나 Red Hat Operator 카탈로그 소스가 수동으로 구성되어 있습니다.

6.3.1. 웹 콘솔을 사용하여 Service Binding Operator 설치

OpenShift Container Platform OperatorHub를 사용하여 Service Binding Operator를 설치할 수 있습니다. Service Binding Operator를 설치하면 서비스 바인딩 구성에 필요한 CR(사용자 정의 리소스)이 Operator와 함께 자동으로 설치됩니다.

절차

  1. 웹 콘솔의 관리자 화면에서 OperatorOperatorHub로 이동합니다.
  2. Filter by keyword 상자를 사용하여 카탈로그에서 Service Binding Operator 를 검색합니다. Service Binding Operator 타일을 클릭합니다.
  3. Service Binding Operator 페이지에서 Operator에 대한 간략한 설명을 읽습니다. 설치를 클릭합니다.
  4. Operator 설치 페이지에서 다음을 수행합니다.

    1. Installation ModeAll namespaces on the cluste(default)를 선택합니다. 이 모드에서는 기본 openshift-operators 네임스페이스에 Operator가 설치되므로 Operator가 클러스터의 모든 네임스페이스를 감시하고 사용 가능하게 만들 수 있습니다.
    2. Approval Strategy으로 Automatic을 선택합니다. 그러면 Operator에 향후 지원되는 업그레이드가 OLM(Operator Lifecycle Manager)에 의해 자동으로 처리됩니다. Manual 승인 전략을 선택하면 OLM에서 업데이트 요청을 생성합니다. 클러스터 관리자는 Operator를 새 버전으로 업데이트하려면 OLM 업데이트 요청을 수동으로 승인해야 합니다.
    3. Update Channel을 선택합니다.

      • 기본적으로 stable 채널을 사용하면 Service Binding Operator의 안정적인 최신 릴리스를 설치할 수 있습니다.
  5. 설치를 클릭합니다.

    참고

    Operator는 openshift-operators 네임스페이스에 자동으로 설치됩니다.

  6. Installed Operator Fuse-freeready for use (사용 가능한 Operator) 창에서 View Operator 를 클릭합니다. Installed Operators 페이지의 목록에 해당 Operator가 나타납니다.
  7. Service Binding Operator가 성공적으로 설치되었는지 확인하려면 상태가 성공으로 설정되어 있는지 확인합니다.

6.3.2. 추가 리소스

6.4. 서비스 바인딩 시작하기

Service Binding Operator는 워크로드 및 지원 서비스의 데이터 플레인을 관리합니다. 이 가이드에서는 데이터베이스 인스턴스를 생성하고, 애플리케이션을 배포하고, Service Binding Operator를 사용하여 애플리케이션과 데이터베이스 서비스 간 바인딩 연결을 생성하는 데 도움이 되는 예제에 대한 지침을 제공합니다.

사전 요구 사항
  • cluster-admin 권한이 있는 계정을 사용하여 OpenShift Container Platform 클러스터에 액세스할 수 있습니다.
  • oc CLI를 설치했습니다.
  • OperatorHub에서 Service Binding Operator를 설치했습니다.
  • v5 업데이트 채널을 사용하여 OperatorHub에서 Kubernetes Operator용 Crunchy Postgres의 5.1.2 버전을 설치했습니다. 설치된 Operator는 my-petclinic 네임스페이스와 같은 적절한 네임스페이스에서 사용할 수 있습니다.

    참고

    oc create namespace my-petclinic 명령을 사용하여 네임스페이스를 생성할 수 있습니다.

6.4.1. PostgreSQL 데이터베이스 인스턴스 생성

PostgreSQL 데이터베이스 인스턴스를 생성하려면 PostgresCluster CR(사용자 정의 리소스)을 생성하고 데이터베이스를 구성해야 합니다.

절차

  1. 쉘에서 다음 명령을 실행하여 my-petclinic 네임스페이스에 PostgresCluster CR을 생성합니다.

    $ oc apply -n my-petclinic -f - << EOD
    ---
    apiVersion: postgres-operator.crunchydata.com/v1beta1
    kind: PostgresCluster
    metadata:
      name: hippo
    spec:
      image: registry.developers.crunchydata.com/crunchydata/crunchy-postgres:ubi8-14.4-0
      postgresVersion: 14
      instances:
        - name: instance1
          dataVolumeClaimSpec:
            accessModes:
            - "ReadWriteOnce"
            resources:
              requests:
                storage: 1Gi
      backups:
        pgbackrest:
          image: registry.developers.crunchydata.com/crunchydata/crunchy-pgbackrest:ubi8-2.38-0
          repos:
          - name: repo1
            volume:
              volumeClaimSpec:
                accessModes:
                - "ReadWriteOnce"
                resources:
                  requests:
                    storage: 1Gi
    EOD

    PostgresCluster CR에 추가된 주석은 서비스 바인딩 연결을 활성화하고 Operator 조정을 트리거합니다.

    출력에서 데이터베이스 인스턴스가 생성되었는지 확인합니다.

    출력 예

    postgrescluster.postgres-operator.crunchydata.com/hippo created

  2. 데이터베이스 인스턴스를 생성한 후 my-petclinic 네임스페이스의 모든 Pod가 실행 중인지 확인합니다.

    $ oc get pods -n my-petclinic

    표시되는 데 몇 분이 걸리는 출력은 데이터베이스가 생성되고 구성되어 있는지 확인합니다.

    출력 예

    NAME                                     READY    STATUS      RESTARTS   AGE
    hippo-backup-9rxm-88rzq                   0/1     Completed   0          2m2s
    hippo-instance1-6psd-0                    4/4     Running     0          3m28s
    hippo-repo-host-0                         2/2     Running     0          3m28s

    데이터베이스를 구성한 후 샘플 애플리케이션을 배포하고 데이터베이스 서비스에 연결할 수 있습니다.

6.4.2. Spring PetClinic 샘플 애플리케이션 배포

OpenShift Container Platform 클러스터에 Spring PetClinic 샘플 애플리케이션을 배포하려면 배포 구성을 사용하고 애플리케이션을 테스트할 수 있도록 로컬 환경을 구성해야 합니다.

절차

  1. 쉘에서 다음 명령을 실행하여 PostgresCluster CR(사용자 정의 리소스)을 사용하여 spring-petclinic 애플리케이션을 배포합니다.

    $ oc apply -n my-petclinic -f - << EOD
    ---
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: spring-petclinic
      labels:
        app: spring-petclinic
    spec:
      replicas: 1
      selector:
        matchLabels:
          app: spring-petclinic
      template:
        metadata:
          labels:
            app: spring-petclinic
        spec:
          containers:
            - name: app
              image: quay.io/service-binding/spring-petclinic:latest
              imagePullPolicy: Always
              env:
              - name: SPRING_PROFILES_ACTIVE
                value: postgres
              ports:
              - name: http
                containerPort: 8080
    ---
    apiVersion: v1
    kind: Service
    metadata:
      labels:
        app: spring-petclinic
      name: spring-petclinic
    spec:
      type: NodePort
      ports:
        - port: 80
          protocol: TCP
          targetPort: 8080
      selector:
        app: spring-petclinic
    EOD

    출력은 Spring PetClinic 샘플 애플리케이션이 생성 및 배포되었는지 확인합니다.

    출력 예

    deployment.apps/spring-petclinic created
    service/spring-petclinic created

    참고

    웹 콘솔의 개발자 화면에서 컨테이너 이미지를 사용하여 애플리케이션을 배포하는 경우 고급 옵션배포 섹션에서 다음 환경 변수를 입력해야 합니다.

    • 이름: SPRING_PROFILES_ACTIVE
    • 값: postgres
  2. 다음 명령을 실행하여 애플리케이션이 데이터베이스 서비스에 아직 연결되어 있지 않은지 확인합니다.

    $ oc get pods -n my-petclinic

    출력에 CrashLoopBackOff 상태를 표시하는 데 몇 분이 걸립니다.

    출력 예

    NAME                                READY   STATUS             RESTARTS      AGE
    spring-petclinic-5b4c7999d4-wzdtz   0/1     CrashLoopBackOff   4 (13s ago)   2m25s

    이 단계에서 Pod가 시작되지 않습니다. 애플리케이션과 상호 작용하려고 하면 오류가 반환됩니다.

  3. 애플리케이션의 경로를 생성하도록 서비스를 노출합니다.

    $ oc expose service spring-petclinic -n my-petclinic

    출력은 Spring -petclinic 서비스가 노출되고 Spring PetClinic 샘플 애플리케이션의 경로가 생성되는지 확인합니다.

    출력 예

    route.route.openshift.io/spring-petclinic exposed

Service Binding Operator를 사용하여 애플리케이션을 데이터베이스 서비스에 연결할 수 있습니다.

6.4.3. Spring PetClinic 샘플 애플리케이션을 PostgreSQL 데이터베이스 서비스에 연결

샘플 애플리케이션을 데이터베이스 서비스에 연결하려면 Service Binding Operator에서 바인딩 데이터를 애플리케이션에 프로젝트하도록 트리거하는 ServiceBinding CR(사용자 정의 리소스)을 생성해야 합니다.

절차

  1. 바인딩 데이터를 프로젝트에 ServiceBinding CR을 생성합니다.

    $ oc apply -n my-petclinic -f - << EOD
    ---
    apiVersion: binding.operators.coreos.com/v1alpha1
    kind: ServiceBinding
    metadata:
      name: spring-petclinic-pgcluster
    spec:
      services: 1
        - group: postgres-operator.crunchydata.com
          version: v1beta1
          kind: PostgresCluster 2
          name: hippo
      application: 3
        name: spring-petclinic
        group: apps
        version: v1
        resource: deployments
    EOD
    1
    서비스 리소스 목록을 지정합니다.
    2
    데이터베이스의 CR입니다.
    3
    포함된 PodSpec을 사용하여 배포 또는 기타 유사한 리소스를 가리키는 샘플 애플리케이션입니다.

    출력에서는 바인딩 데이터를 샘플 애플리케이션에 투영하기 위해 ServiceBinding CR이 생성되었는지 확인합니다.

    출력 예

    servicebinding.binding.operators.coreos.com/spring-petclinic created

  2. 서비스 바인딩 요청이 성공했는지 확인합니다.

    $ oc get servicebindings -n my-petclinic

    출력 예

    NAME                         READY   REASON              AGE
    spring-petclinic-pgcluster   True    ApplicationsBound   7s

    기본적으로 데이터베이스 서비스의 바인딩 데이터의 값은 샘플 애플리케이션을 실행하는 워크로드 컨테이너에 파일로 프로젝션됩니다. 예를 들어 Secret 리소스의 모든 값은 bindings/spring-petclinic-pgcluster 디렉터리에 프로젝션됩니다.

    참고

    필요한 경우 디렉터리 콘텐츠를 인쇄하여 애플리케이션의 파일에 예상 바인딩 데이터가 포함되어 있는지 확인할 수도 있습니다.

    $ for i in username password host port type; do oc exec -it deploy/spring-petclinic -n my-petclinic -- /bin/bash -c 'cd /tmp; find /bindings/*/'$i' -exec echo -n {}:" " \; -exec cat {} \;'; echo; done

    출력 예: 보안 리소스의 모든 값 사용

    /bindings/spring-petclinic-pgcluster/username: <username>
    /bindings/spring-petclinic-pgcluster/password: <password>
    /bindings/spring-petclinic-pgcluster/host: hippo-primary.my-petclinic.svc
    /bindings/spring-petclinic-pgcluster/port: 5432
    /bindings/spring-petclinic-pgcluster/type: postgresql

  3. 로컬 환경에서 샘플 애플리케이션에 액세스하도록 애플리케이션 포트에서 포트 전달을 설정합니다.

    $ oc port-forward --address 0.0.0.0 svc/spring-petclinic 8080:80 -n my-petclinic

    출력 예

    Forwarding from 0.0.0.0:8080 -> 8080
    Handling connection for 8080

  4. http://localhost:8080/petclinic 에 액세스합니다.

    이제 localhost:8080에서 Spring PetClinic 샘플 애플리케이션에 원격으로 액세스할 수 있으며 애플리케이션이 이제 데이터베이스 서비스에 연결되어 있음을 확인할 수 있습니다.

6.4.4. 추가 리소스

6.5. IBM Power, IBM Z 및 IBM(R) LinuxONE에서 서비스 바인딩 시작하기

Service Binding Operator는 워크로드 및 지원 서비스의 데이터 플레인을 관리합니다. 이 가이드에서는 데이터베이스 인스턴스를 생성하고, 애플리케이션을 배포하고, Service Binding Operator를 사용하여 애플리케이션과 데이터베이스 서비스 간 바인딩 연결을 생성하는 데 도움이 되는 예제에 대한 지침을 제공합니다.

사전 요구 사항
  • cluster-admin 권한이 있는 계정을 사용하여 OpenShift Container Platform 클러스터에 액세스할 수 있습니다.
  • oc CLI를 설치했습니다.
  • OperatorHub에서 Service Binding Operator를 설치했습니다.

6.5.1. PostgreSQL Operator 배포

절차

  1. my-petclinic 네임스페이스에 Dev4Devs PostgreSQL Operator를 배포하려면 쉘에서 다음 명령을 실행합니다.
$ oc apply -f - << EOD
---
apiVersion: v1
kind: Namespace
metadata:
  name: my-petclinic
---
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: postgres-operator-group
  namespace: my-petclinic
---
apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: ibm-multiarch-catalog
  namespace: openshift-marketplace
spec:
  sourceType: grpc
  image: quay.io/ibm/operator-registry-<architecture> 1
  imagePullPolicy: IfNotPresent
  displayName: ibm-multiarch-catalog
  updateStrategy:
    registryPoll:
      interval: 30m
---
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: postgresql-operator-dev4devs-com
  namespace: openshift-operators
spec:
  channel: alpha
  installPlanApproval: Automatic
  name: postgresql-operator-dev4devs-com
  source: ibm-multiarch-catalog
  sourceNamespace: openshift-marketplace
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: database-view
  labels:
    servicebinding.io/controller: "true"
rules:
  - apiGroups:
      - postgresql.dev4devs.com
    resources:
      - databases
    verbs:
      - get
      - list
EOD
1
Operator 이미지입니다.
  • IBM Power의 경우: quay.io/ibm/operator-registry-ppc64le:release-4.9
  • IBM Z 및 IBM® LinuxONE의 경우: quay.io/ibm/operator-registry-s390x:release-4.8

검증

  1. Operator가 설치되면 openshift-operators 네임스페이스에 Operator 서브스크립션을 나열합니다.

    $ oc get subs -n openshift-operators

    출력 예

    NAME                               PACKAGE                            SOURCE                  CHANNEL
    postgresql-operator-dev4devs-com   postgresql-operator-dev4devs-com   ibm-multiarch-catalog   alpha
    rh-service-binding-operator        rh-service-binding-operator        redhat-operators        stable

6.5.2. PostgreSQL 데이터베이스 인스턴스 생성

PostgreSQL 데이터베이스 인스턴스를 생성하려면 데이터베이스 사용자 정의 리소스(CR)를 생성하고 데이터베이스를 구성해야 합니다.

절차

  1. 쉘에서 다음 명령을 실행하여 my-petclinic 네임스페이스에 Database CR을 생성합니다.

    $ oc apply -f - << EOD
    apiVersion: postgresql.dev4devs.com/v1alpha1
    kind: Database
    metadata:
      name: sampledatabase
      namespace: my-petclinic
      annotations:
        host: sampledatabase
        type: postgresql
        port: "5432"
        service.binding/database: 'path={.spec.databaseName}'
        service.binding/port: 'path={.metadata.annotations.port}'
        service.binding/password: 'path={.spec.databasePassword}'
        service.binding/username: 'path={.spec.databaseUser}'
        service.binding/type: 'path={.metadata.annotations.type}'
        service.binding/host: 'path={.metadata.annotations.host}'
    spec:
      databaseCpu: 30m
      databaseCpuLimit: 60m
      databaseMemoryLimit: 512Mi
      databaseMemoryRequest: 128Mi
      databaseName: "sampledb"
      databaseNameKeyEnvVar: POSTGRESQL_DATABASE
      databasePassword: "samplepwd"
      databasePasswordKeyEnvVar: POSTGRESQL_PASSWORD
      databaseStorageRequest: 1Gi
      databaseUser: "sampleuser"
      databaseUserKeyEnvVar: POSTGRESQL_USER
      image: registry.redhat.io/rhel8/postgresql-13:latest
      databaseStorageClassName: nfs-storage-provisioner
      size: 1
    EOD

    Database CR에 추가된 주석은 서비스 바인딩 연결을 활성화하고 Operator 조정을 트리거합니다.

    출력에서 데이터베이스 인스턴스가 생성되었는지 확인합니다.

    출력 예

    database.postgresql.dev4devs.com/sampledatabase created

  2. 데이터베이스 인스턴스를 생성한 후 my-petclinic 네임스페이스의 모든 Pod가 실행 중인지 확인합니다.

    $ oc get pods -n my-petclinic

    표시되는 데 몇 분이 걸리는 출력은 데이터베이스가 생성되고 구성되어 있는지 확인합니다.

    출력 예

    NAME                                     READY    STATUS      RESTARTS   AGE
    sampledatabase-cbc655488-74kss            0/1     Running        0       32s

데이터베이스를 구성한 후 샘플 애플리케이션을 배포하고 데이터베이스 서비스에 연결할 수 있습니다.

6.5.3. Spring PetClinic 샘플 애플리케이션 배포

OpenShift Container Platform 클러스터에 Spring PetClinic 샘플 애플리케이션을 배포하려면 배포 구성을 사용하고 애플리케이션을 테스트할 수 있도록 로컬 환경을 구성해야 합니다.

절차

  1. 쉘에서 다음 명령을 실행하여 PostgresCluster CR(사용자 정의 리소스)을 사용하여 spring-petclinic 애플리케이션을 배포합니다.

    $ oc apply -n my-petclinic -f - << EOD
    ---
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: spring-petclinic
      labels:
        app: spring-petclinic
    spec:
      replicas: 1
      selector:
        matchLabels:
          app: spring-petclinic
      template:
        metadata:
          labels:
            app: spring-petclinic
        spec:
          containers:
            - name: app
              image: quay.io/service-binding/spring-petclinic:latest
              imagePullPolicy: Always
              env:
              - name: SPRING_PROFILES_ACTIVE
                value: postgres
              - name: org.springframework.cloud.bindings.boot.enable
                value: "true"
              ports:
              - name: http
                containerPort: 8080
    ---
    apiVersion: v1
    kind: Service
    metadata:
      labels:
        app: spring-petclinic
      name: spring-petclinic
    spec:
      type: NodePort
      ports:
        - port: 80
          protocol: TCP
          targetPort: 8080
      selector:
        app: spring-petclinic
    EOD

    출력은 Spring PetClinic 샘플 애플리케이션이 생성 및 배포되었는지 확인합니다.

    출력 예

    deployment.apps/spring-petclinic created
    service/spring-petclinic created

    참고

    웹 콘솔의 개발자 화면에서 컨테이너 이미지를 사용하여 애플리케이션을 배포하는 경우 고급 옵션배포 섹션에서 다음 환경 변수를 입력해야 합니다.

    • 이름: SPRING_PROFILES_ACTIVE
    • 값: postgres
  2. 다음 명령을 실행하여 애플리케이션이 데이터베이스 서비스에 아직 연결되어 있지 않은지 확인합니다.

    $ oc get pods -n my-petclinic

    CrashLoopBackOff 상태가 표시될 때까지 몇 분이 걸립니다.

    출력 예

    NAME                                READY   STATUS             RESTARTS      AGE
    spring-petclinic-5b4c7999d4-wzdtz   0/1     CrashLoopBackOff   4 (13s ago)   2m25s

    이 단계에서 Pod가 시작되지 않습니다. 애플리케이션과 상호 작용하려고 하면 오류가 반환됩니다.

Service Binding Operator를 사용하여 애플리케이션을 데이터베이스 서비스에 연결할 수 있습니다.

6.5.4. Spring PetClinic 샘플 애플리케이션을 PostgreSQL 데이터베이스 서비스에 연결

샘플 애플리케이션을 데이터베이스 서비스에 연결하려면 Service Binding Operator에서 바인딩 데이터를 애플리케이션에 프로젝트하도록 트리거하는 ServiceBinding CR(사용자 정의 리소스)을 생성해야 합니다.

절차

  1. 바인딩 데이터를 프로젝트에 ServiceBinding CR을 생성합니다.

    $ oc apply -n my-petclinic -f - << EOD
    ---
    apiVersion: binding.operators.coreos.com/v1alpha1
    kind: ServiceBinding
    metadata:
        name: spring-petclinic-pgcluster
    spec:
      services: 1
        - group: postgresql.dev4devs.com
          kind: Database 2
          name: sampledatabase
          version: v1alpha1
      application: 3
        name: spring-petclinic
        group: apps
        version: v1
        resource: deployments
    EOD
    1
    서비스 리소스 목록을 지정합니다.
    2
    데이터베이스의 CR입니다.
    3
    포함된 PodSpec을 사용하여 배포 또는 기타 유사한 리소스를 가리키는 샘플 애플리케이션입니다.

    출력에서는 바인딩 데이터를 샘플 애플리케이션에 투영하기 위해 ServiceBinding CR이 생성되었는지 확인합니다.

    출력 예

    servicebinding.binding.operators.coreos.com/spring-petclinic created

  2. 서비스 바인딩 요청이 성공했는지 확인합니다.

    $ oc get servicebindings -n my-petclinic

    출력 예

    NAME                          READY   REASON              AGE
    spring-petclinic-postgresql   True    ApplicationsBound   47m

    기본적으로 데이터베이스 서비스의 바인딩 데이터의 값은 샘플 애플리케이션을 실행하는 워크로드 컨테이너에 파일로 프로젝션됩니다. 예를 들어 Secret 리소스의 모든 값은 bindings/spring-petclinic-pgcluster 디렉터리에 프로젝션됩니다.

  3. 이 값이 생성되면 토폴로지로 이동하여 시각적 연결을 확인할 수 있습니다.

    그림 6.1. Spring-petclinic을 샘플 데이터베이스에 연결

    img power
  4. 로컬 환경에서 샘플 애플리케이션에 액세스하도록 애플리케이션 포트에서 포트 전달을 설정합니다.

    $ oc port-forward --address 0.0.0.0 svc/spring-petclinic 8080:80 -n my-petclinic

    출력 예

    Forwarding from 0.0.0.0:8080 -> 8080
    Handling connection for 8080

  5. http://localhost:8080 에 액세스합니다.

    이제 localhost:8080에서 Spring PetClinic 샘플 애플리케이션에 원격으로 액세스할 수 있으며 애플리케이션이 이제 데이터베이스 서비스에 연결되어 있음을 확인할 수 있습니다.

6.5.5. 추가 리소스

6.6. 서비스에서 바인딩 데이터 노출

애플리케이션 개발자는 워크로드를 빌드하고 연결하기 위해 서비스를 백업하기 위한 액세스 권한이 필요합니다. 워크로드를 백업 서비스에 연결하면 각 서비스 공급자가 보안에 액세스하고 워크로드에서 사용할 수 있는 다른 방법이 필요하기 때문에 항상 문제가 됩니다.

Service Binding Operator를 사용하면 수동 프로시저로 바인딩 연결을 구성하지 않고도 애플리케이션 개발자가 Operator 관리 백업 서비스와 함께 워크로드를 쉽게 바인딩할 수 있습니다. Service Binding Operator가 바인딩 데이터를 제공하려면 백업 서비스를 생성하는 Operator 공급자 또는 사용자가 바인딩 데이터를 노출하여 Service Binding Operator에서 자동으로 감지할 바인딩 데이터를 노출해야 합니다. 그런 다음 Service Binding Operator는 백업 서비스에서 바인딩 데이터를 자동으로 수집하고 이를 워크로드와 공유하여 일관되고 예측 가능한 환경을 제공합니다.

6.6.1. 바인딩 데이터를 노출하는 방법

이 섹션에서는 바인딩 데이터를 노출하는 데 사용할 수 있는 방법에 대해 설명합니다.

워크로드 요구 사항 및 환경을 이해하고, 제공된 서비스에서 작동하는 방법을 이해하고 있는지 확인하십시오.

바인딩 데이터는 다음과 같은 상황에서 노출됩니다.

  • 백업 서비스는 프로비저닝된 서비스 리소스로 사용할 수 있습니다.

    연결하려는 서비스는 Service Binding 사양을 준수합니다. 필요한 모든 바인딩 데이터 값을 사용하여 Secret 리소스를 생성하고 백업 서비스 CR(사용자 정의 리소스)에서 참조해야 합니다. 모든 바인딩 데이터 값의 검색은 자동으로 수행됩니다.

  • 백업 서비스는 프로비저닝된 서비스 리소스로 사용할 수 없습니다.

    백업 서비스에서 바인딩 데이터를 노출해야 합니다. 워크로드 요구 사항 및 환경에 따라 다음 방법 중 하나를 선택하여 바인딩 데이터를 노출할 수 있습니다.

    • 직접 시크릿 참조
    • CRD(사용자 정의 리소스 정의) 또는 CR 주석을 통해 바인딩 데이터 선언
    • 소유 리소스를 통해 바인딩 데이터 검색
6.6.1.1. 프로비저닝된 서비스

프로비저닝된 서비스는 지원 서비스 CR의 .status.binding.name 필드에 있는 Secret 리소스에 대한 참조가 있는 백업 서비스 CR을 나타냅니다.

백업 서비스를 생성하는 Operator 공급자 또는 사용자는 이 방법을 사용하여 Secret 리소스를 생성하고 백업 서비스 CR의 .status.binding.name 섹션에서 참조하여 Service Binding 사양을 준수할 수 있습니다. 이 보안 리소스는 워크로드가 백업 서비스에 연결하는 데 필요한 모든 바인딩 데이터 값을 제공해야 합니다.

다음 예제에서는 CR에서 참조하는 백업 서비스 및 Secret 리소스를 나타내는 AccountService CR을 보여줍니다.

예: AccountService CR

apiVersion: example.com/v1alpha1
kind: AccountService
name: prod-account-service
spec:
# ...
status:
  binding:
    name: hippo-pguser-hippo

예: 참조된 시크릿 리소스

apiVersion: v1
kind: Secret
metadata:
  name: hippo-pguser-hippo
data:
  password: "<password>"
  user: "<username>"
# ...

서비스 바인딩 리소스를 생성할 때 다음과 같이 ServiceBinding 사양에 있는 AccountService 리소스의 세부 정보를 직접 제공할 수 있습니다.

예: ServiceBinding 리소스

apiVersion: binding.operators.coreos.com/v1alpha1
kind: ServiceBinding
metadata:
  name: account-service
spec:
# ...
  services:
  - group: "example.com"
    version: v1alpha1
    kind: AccountService
    name: prod-account-service
  application:
    name: spring-petclinic
    group: apps
    version: v1
    resource: deployments

예: 사양 API의 ServiceBinding 리소스

apiVersion: servicebinding.io/v1beta1
kind: ServiceBinding
metadata:
  name: account-service
spec:
# ...
  service:
    apiVersion: example.com/v1alpha1
    kind: AccountService
    name: prod-account-service
  workload:
    apiVersion: apps/v1
    kind: Deployment
    name: spring-petclinic

이 메서드는 hippo-pguser-hippo 참조 Secret 리소스의 모든 키를 워크로드에 프로젝션할 바인딩 데이터로 노출합니다.

6.6.1.2. 직접 시크릿 참조

Service Binding 정의에서 참조할 수 있는 Secret 리소스에서 필요한 바인딩 데이터 값을 모두 사용할 수 있는 경우 이 메서드를 사용할 수 있습니다.You can use this method, if all the required binding data values are available in a Secret resource that you can reference in your Service Binding definition. 이 메서드에서 ServiceBinding 리소스는 서비스에 연결하기 위해 Secret 리소스를 직접 참조합니다. Secret 리소스의 모든 키는 바인딩 데이터로 노출됩니다.

예: binding.operators.coreos.com API를 사용한 사양

apiVersion: binding.operators.coreos.com/v1alpha1
kind: ServiceBinding
metadata:
  name: account-service
spec:
# ...
  services:
  - group: ""
    version: v1
    kind: Secret
    name: hippo-pguser-hippo

예: servicebinding.io API를 준수하는 사양

apiVersion: servicebinding.io/v1beta1
kind: ServiceBinding
metadata:
  name: account-service
spec:
# ...
  service:
    apiVersion: v1
    kind: Secret
    name: hippo-pguser-hippo

6.6.1.3. CRD 또는 CR 주석을 통해 바인딩 데이터 선언

이 방법을 사용하여 백업 서비스의 리소스에 주석을 달아 바인딩 데이터를 특정 주석으로 노출할 수 있습니다. metadata 섹션에 주석을 추가하면 백업 서비스의 CR 및 CRD가 변경됩니다. Service Binding Operator는 CR 및 CRD에 추가된 주석을 감지한 다음 주석을 기반으로 추출된 값을 사용하여 Secret 리소스를 생성합니다.

다음 예제에서는 metadata 섹션에 추가된 주석과 리소스에서 참조되는 ConfigMap 오브젝트를 보여줍니다.

예: CR 주석에 정의된 Secret 오브젝트에서 바인딩 데이터 노출

apiVersion: postgres-operator.crunchydata.com/v1beta1
kind: PostgresCluster
metadata:
  name: hippo
  namespace: my-petclinic
  annotations:
    service.binding: 'path={.metadata.name}-pguser-{.metadata.name},objectType=Secret'
# ...

이전 예제에서는 hippo-pguser-hippo 로 확인되는 {.metadata.name}-pguser-{.metadata.name} 템플릿에 시크릿 이름의 이름을 배치합니다. 템플릿은 여러 JSONPath 표현식을 포함할 수 있습니다.

예: 리소스의 Secret 오브젝트 참조

apiVersion: v1
kind: Secret
metadata:
  name: hippo-pguser-hippo
data:
  password: "<password>"
  user: "<username>"

예: CR 주석에 정의된 ConfigMap 오브젝트에서 바인딩 데이터 노출

apiVersion: postgres-operator.crunchydata.com/v1beta1
kind: PostgresCluster
metadata:
  name: hippo
  namespace: my-petclinic
  annotations:
    service.binding: 'path={.metadata.name}-config,objectType=ConfigMap'
# ...

이전 예제에서는 hippo-config 로 확인되는 {.metadata.name}-config 템플릿에 구성 맵의 이름을 배치합니다. 템플릿은 여러 JSONPath 표현식을 포함할 수 있습니다.

예: 리소스의 ConfigMap 오브젝트 참조

apiVersion: v1
kind: ConfigMap
metadata:
  name: hippo-config
data:
  db_timeout: "10s"
  user: "hippo"

6.6.1.4. 소유 리소스를 통해 바인딩 데이터 검색

백업 서비스에 바인딩 데이터를 감지하는 데 사용할 수 있는 경로, 서비스, 구성 맵 또는 시크릿과 같은 하나 이상의 Kubernetes 리소스가 있는 경우 이 방법을 사용할 수 있습니다. 이 메서드에서 Service Binding Operator는 백업 서비스 CR이 소유한 리소스의 바인딩 데이터를 탐지합니다.

다음 예제에서는 ServiceBinding CR에서 true 로 설정된 detectBindingResources API 옵션을 보여줍니다.

예제

apiVersion: binding.operators.coreos.com/v1alpha1
kind: ServiceBinding
metadata:
  name: spring-petclinic-detect-all
  namespace: my-petclinic
spec:
  detectBindingResources: true
  services:
    - group: postgres-operator.crunchydata.com
      version: v1beta1
      kind: PostgresCluster
      name: hippo
  application:
    name: spring-petclinic
    group: apps
    version: v1
    resource: deployments

이전 예에서 PostgresCluster 사용자 정의 서비스 리소스에는 경로, 서비스, 구성 맵 또는 시크릿과 같은 하나 이상의 Kubernetes 리소스가 있습니다.

Service Binding Operator는 각 보유 리소스에 노출된 바인딩 데이터를 자동으로 탐지합니다.

6.6.2. 데이터 모델

주석에 사용되는 데이터 모델은 특정 규칙을 따릅니다.

서비스 바인딩 주석에는 다음 규칙을 사용해야 합니다.

service.binding(/<NAME>)?:
    "<VALUE>|(path=<JSONPATH_TEMPLATE>(,objectType=<OBJECT_TYPE>)?(,elementType=<ELEMENT_TYPE>)?(,sourceKey=<SOURCE_KEY>)?(,sourceValue=<SOURCE_VALUE>)?)"

다음과 같습니다.

<NAME>

바인딩 값을 노출할 이름을 지정합니다. objectType 매개변수가 Secret 또는 ConfigMap 으로 설정된 경우에만 제외할 수 있습니다.

<VALUE>

경로가 설정되지 않은 경우 노출된 상수 값을 지정합니다.

데이터 모델은 경로에 허용되는 값과 의미에 대한 세부 정보를 제공합니다. ,elementType,objectType,sourceKey, sourceValue 매개변수입니다.

표 6.4. 매개 변수 및 설명
매개변수설명기본값

경로

중괄호로 묶은 JSONPath 표현식을 구성하는 JSONPath 템플릿입니다.

해당 없음

elementType

path 매개변수에서 참조하는 요소의 값이 다음 유형 중 하나를 준수하는지 여부를 지정합니다.

  • string
  • sliceOfStrings
  • sliceOfMaps

string

objectType

path 매개변수에 표시된 요소의 값이 현재 네임스페이스의 ConfigMap,Secret 또는 plain 문자열을 참조하는지 여부를 지정합니다.

secret, elementType 이 문자열이 아닌 경우입니다.

sourceKey

바인딩 데이터를 수집할 때 바인딩 보안에 추가할 ConfigMap 또는 Secret 리소스의 키를 지정합니다.

참고:

  • elementType=sliceOfMaps 와 함께 사용하는 경우 sourceKey 매개변수는 바인딩 시크릿에서 값으로 사용되는 맵 조각의 키를 지정합니다.
  • 이 선택적 매개변수를 사용하여 참조된 Secret 또는 ConfigMap 리소스에서 특정 항목을 바인딩 데이터로 노출합니다.
  • 지정하지 않으면 Secret 또는 ConfigMap 리소스의 모든 키와 값이 노출되어 바인딩 보안에 추가됩니다.

해당 없음

sourceValue

맵 조각의 키를 지정합니다.

참고:

  • 이 키의 값은 바인딩 보안에 추가할 키-값 쌍에 대한 항목의 값을 생성하는 기반으로 사용됩니다.
  • 또한 sourceKey 값은 바인딩 보안에 추가할 키-값 쌍의 항목의 키로 사용됩니다.
  • elementType=sliceOfMaps 에서만 필수입니다.

해당 없음

참고

sourceKeysourceValue 매개변수는 path 매개변수에 표시된 요소가 ConfigMap 또는 Secret 리소스를 참조하는 경우에만 적용할 수 있습니다.

6.6.3. 주석 매핑을 선택 옵션으로 설정

주석에 선택적 필드가 있을 수 있습니다. 예를 들어 서비스 엔드포인트에 인증이 필요하지 않은 경우 자격 증명 경로는 표시되지 않을 수 있습니다. 이러한 경우 주석의 대상 경로에 필드가 존재하지 않을 수 있습니다. 결과적으로 Service Binding Operator는 기본적으로 오류를 생성합니다.

서비스 공급자로서 주석 매핑이 필요한지 여부를 나타내기 위해 서비스를 활성화할 때 주석에 선택적 플래그 값을 설정할 수 있습니다. Service Binding Operator는 대상 경로를 사용할 수 있는 경우에만 주석 매핑을 제공합니다. 대상 경로를 사용할 수 없는 경우 Service Binding Operator는 선택적 매핑을 건너뛰고 오류를 발생시키지 않고 기존 매핑의 예상을 계속합니다.

절차

  • 주석에서 필드를 선택적으로 만들려면 선택적 플래그 값을 true 로 설정합니다.

    예제

    apiVersion: apps.example.org/v1beta1
    kind: Database
    metadata:
      name: my-db
      namespace: my-petclinic
      annotations:
        service.binding/username: path={.spec.name},optional=true
    # ...

참고
  • 선택적 플래그 값을 false 로 설정하고 Service Binding Operator에서 대상 경로를 찾을 수 없는 경우 Operator가 주석 매핑에 실패합니다.
  • 선택적 플래그에 값이 설정되지 않은 경우 Service Binding Operator는 기본적으로 값을 false 로 간주하고 주석 매핑에 실패합니다.

6.6.4. RBAC 요구사항

Service Binding Operator를 사용하여 백업 서비스 바인딩 데이터를 노출하려면 특정 RBAC(역할 기반 액세스 제어) 권한이 필요합니다. ClusterRole 리소스의 rules 필드에 특정 동사를 지정하여 백업 서비스 리소스에 대한 RBAC 권한을 부여합니다. 이러한 규칙을 정의할 때 Service Binding Operator에서 클러스터 전체에서 백업 서비스 리소스의 바인딩 데이터를 읽을 수 있습니다. 사용자에게 바인딩 데이터를 읽거나 애플리케이션 리소스를 수정할 수 있는 권한이 없는 경우 Service Binding Operator는 이러한 사용자가 서비스를 애플리케이션에 바인딩하지 못하도록 합니다. RBAC 요구 사항을 준수하면 사용자에게 불필요한 권한 승격을 방지하고 권한 없는 서비스 또는 애플리케이션에 대한 액세스를 방지할 수 있습니다.

Service Binding Operator는 전용 서비스 계정을 사용하여 Kubernetes API에 대한 요청을 수행합니다. 기본적으로 이 계정에는 다음과 같은 표준 Kubernetes 또는 OpenShift 오브젝트로 표시되는 워크로드에 서비스를 바인딩할 수 있는 권한이 있습니다.

  • 배포
  • DaemonSets
  • ReplicaSets
  • StatefulSets
  • DeploymentConfigs

Operator 서비스 계정은 집계된 클러스터 역할에 바인딩되어 Operator 공급자 또는 클러스터 관리자가 사용자 정의 서비스 리소스를 워크로드에 바인딩할 수 있습니다. ClusterRole 내에서 필요한 권한을 부여하려면 servicebinding.io/controller 플래그를 사용하여 레이블을 지정하고 플래그 값을 true 로 설정합니다. 다음 예제는 Service Binding Operator가 Crunchy PostgreSQL Operator의 CR(사용자 정의 리소스)을 가져오고 감시하고 나열 하도록 허용하는 방법을 보여줍니다.

예: Crunchy PostgreSQL Operator에서 프로비저닝한 PostgreSQL 데이터베이스 인스턴스에 바인딩 사용

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: postgrescluster-reader
  labels:
     servicebinding.io/controller: "true"
rules:
- apiGroups:
    - postgres-operator.crunchydata.com
  resources:
    - postgresclusters
  verbs:
    - get
    - watch
    - list
  ...

이 클러스터 역할은 백업 서비스 Operator를 설치하는 동안 배포할 수 있습니다.

6.6.5. 노출 가능한 바인딩 데이터 범주

Service Binding Operator를 사용하면 백업 서비스 리소스 및 CRD(사용자 정의 리소스 정의)에서 바인딩 데이터 값을 노출할 수 있습니다.

이 섹션에서는 노출 가능한 바인딩 데이터의 다양한 카테고리를 사용하는 방법을 보여주는 예제를 제공합니다. 작업 환경 및 요구 사항에 맞게 이러한 예제를 수정해야 합니다.

6.6.5.1. 리소스에서 문자열 노출

다음 예제에서는 PostgresCluster CR(사용자 정의 리소스)의 metadata.name 필드에서 사용자 이름으로 문자열을 노출하는 방법을 보여줍니다.

예제

apiVersion: postgres-operator.crunchydata.com/v1beta1
kind: PostgresCluster
metadata:
  name: hippo
  namespace: my-petclinic
  annotations:
    service.binding/username: path={.metadata.name}
# ...

6.6.5.2. 상수 값을 바인딩 항목으로 노출

다음 예제에서는 PostgresCluster CR(사용자 정의 리소스)의 상수 값을 노출하는 방법을 보여줍니다.

예: 상수 값 노출

apiVersion: postgres-operator.crunchydata.com/v1beta1
kind: PostgresCluster
metadata:
  name: hippo
  namespace: my-petclinic
  annotations:
    "service.binding/type": "postgresql" 1

1
postgresql 값으로 노출되는 바인딩 유형입니다.
6.6.5.3. 리소스에서 참조되는 전체 구성 맵 또는 시크릿 노출

다음 예제에서는 주석을 통해 전체 보안을 노출하는 방법을 보여줍니다.

예: 주석을 통해 전체 시크릿 노출

apiVersion: postgres-operator.crunchydata.com/v1beta1
kind: PostgresCluster
metadata:
  name: hippo
  namespace: my-petclinic
  annotations:
    service.binding: 'path={.metadata.name}-pguser-{.metadata.name},objectType=Secret'

예: 백업 서비스 리소스에서 참조된 시크릿

apiVersion: v1
kind: Secret
metadata:
  name: hippo-pguser-hippo
data:
  password: "<password>"
  user: "<username>"

6.6.5.4. 리소스에서 참조되는 구성 맵 또는 시크릿에서 특정 항목 노출

다음 예제에서는 주석을 통해 구성 맵의 특정 항목을 노출하는 방법을 보여줍니다.

예: 구성 맵에서 주석을 통해 항목 노출

apiVersion: postgres-operator.crunchydata.com/v1beta1
kind: PostgresCluster
metadata:
  name: hippo
  namespace: my-petclinic
  annotations:
    service.binding: 'path={.metadata.name}-config,objectType=ConfigMap,sourceKey=user'

예: 백업 서비스 리소스의 참조된 구성 맵

바인딩 데이터에는 이름이 db_timeout 이고 값이 10s 인 키가 있어야 합니다.

apiVersion: v1
kind: ConfigMap
metadata:
  name: hippo-config
data:
  db_timeout: "10s"
  user: "hippo"
6.6.5.5. 리소스 정의 값 노출

다음 예제에서는 주석을 통해 리소스 정의 값을 노출하는 방법을 보여줍니다.

예: 주석을 통해 리소스 정의 값 노출

apiVersion: postgres-operator.crunchydata.com/v1beta1
kind: PostgresCluster
metadata:
  name: hippo
  namespace: my-petclinic
  annotations:
    service.binding/username: path={.metadata.name}
    ...

6.6.5.6. 각 항목에서 키와 값을 사용하여 컬렉션의 항목 노출

다음 예제에서는 각 항목의 키와 값으로 컬렉션의 항목을 주석까지 노출하는 방법을 보여줍니다.

예: 주석을 통해 컬렉션 항목 노출

apiVersion: postgres-operator.crunchydata.com/v1beta1
kind: PostgresCluster
metadata:
  name: hippo
  namespace: my-petclinic
  annotations:
    "service.binding/uri": "path={.status.connections},elementType=sliceOfMaps,sourceKey=type,sourceValue=url"
spec:
# ...
status:
  connections:
    - type: primary
      url: primary.example.com
    - type: secondary
      url: secondary.example.com
    - type: '404'
      url: black-hole.example.com

다음 예제에서는 주석에서 컬렉션의 이전 항목이 바인딩된 애플리케이션으로 예상되는 방법을 보여줍니다.

예: 바인딩 데이터 파일

/bindings/<binding-name>/uri_primary => primary.example.com
/bindings/<binding-name>/uri_secondary => secondary.example.com
/bindings/<binding-name>/uri_404 => black-hole.example.com

예: 백업 서비스 리소스에서 구성

status:
  connections:
    - type: primary
      url: primary.example.com
    - type: secondary
      url: secondary.example.com
    - type: '404'
      url: black-hole.example.com

이전 예제에서는 기본,보조 등과 같은 키를 사용하여 모든 값을 예상하는 데 도움이 됩니다.

6.6.5.7. 항목당 하나의 키를 사용하여 컬렉션의 항목 노출

다음 예제에서는 주석을 통해 항목당 하나의 키를 사용하여 컬렉션의 항목을 노출하는 방법을 보여줍니다.

예: 주석을 통해 컬렉션 항목 노출

apiVersion: postgres-operator.crunchydata.com/v1beta1
kind: PostgresCluster
metadata:
  name: hippo
  namespace: my-petclinic
  annotations:
    "service.binding/tags": "path={.spec.tags},elementType=sliceOfStrings"
spec:
    tags:
      - knowledge
      - is
      - power

다음 예제에서는 주석에서 컬렉션의 이전 항목이 바인딩된 애플리케이션으로 프로젝션되는 방법을 보여줍니다.

예: 바인딩 데이터 파일

/bindings/<binding-name>/tags_0 => knowledge
/bindings/<binding-name>/tags_1 => is
/bindings/<binding-name>/tags_2 => power

예: 백업 서비스 리소스에서 구성

spec:
  tags:
  - knowledge
  - is
  - power

6.6.5.8. 항목당 하나의 키를 사용하여 컬렉션 항목의 값 노출

다음 예제에서는 주석을 통해 항목 값당 하나의 키를 사용하여 컬렉션 항목 값을 노출하는 방법을 보여줍니다.

예: 주석을 통해 컬렉션 항목 값 노출

apiVersion: postgres-operator.crunchydata.com/v1beta1
kind: PostgresCluster
metadata:
  name: hippo
  namespace: my-petclinic
  annotations:
    "service.binding/url": "path={.spec.connections},elementType=sliceOfStrings,sourceValue=url"
spec:
  connections:
    - type: primary
      url: primary.example.com
    - type: secondary
      url: secondary.example.com
    - type: '404'
      url: black-hole.example.com

다음 예제에서는 주석의 컬렉션의 이전 값이 바인딩된 애플리케이션으로 예상되는 방법을 보여줍니다.

예: 바인딩 데이터 파일

/bindings/<binding-name>/url_0 => primary.example.com
/bindings/<binding-name>/url_1 => secondary.example.com
/bindings/<binding-name>/url_2 => black-hole.example.com

6.6.6. 추가 리소스

6.7. 바인딩 데이터 프로젝션

이 섹션에서는 바인딩 데이터를 사용하는 방법에 대한 정보를 제공합니다.

6.7.1. 바인딩 데이터 사용

백업 서비스에서 바인딩 데이터를 노출한 후 워크로드에서 이 데이터에 액세스하고 사용할 수 있도록 백업 서비스의 워크로드에 프로젝트를 수행해야 합니다. Service Binding Operator는 다음 방법의 워크로드에 이러한 데이터 세트를 자동으로 프로젝트합니다.

  1. 기본적으로 는 파일로 설정됩니다.
  2. 환경 변수로 ServiceBinding 리소스에서 .spec.bindAsFiles 매개변수를 구성한 후

6.7.2. 워크로드 컨테이너 내에서 바인딩 데이터를 프로젝트에 사용할 디렉터리 경로 구성

기본적으로 Service Binding Operator는 바인딩 데이터를 워크로드 리소스의 특정 디렉터리에 파일로 마운트합니다. 워크로드가 실행되는 컨테이너에서 SERVICE_BINDING_ROOT 환경 변수 설정을 사용하여 디렉터리 경로를 구성할 수 있습니다.

예: 파일로 마운트된 바인딩 데이터

$SERVICE_BINDING_ROOT 1
├── account-database 2
│   ├── type 3
│   ├── provider 4
│   ├── uri
│   ├── username
│   └── password
└── transaction-event-stream 5
    ├── type
    ├── connection-count
    ├── uri
    ├── certificates
    └── private-key

1
루트 디렉터리.
2 5
바인딩 데이터를 저장하는 디렉터리입니다.
3
해당 디렉터리에 예상된 바인딩 데이터 유형을 식별하는 필수 식별자입니다.
4
선택 사항: 애플리케이션에서 연결할 수 있는 백업 서비스 유형을 식별할 수 있도록 공급자를 식별하는 식별자입니다.

바인딩 데이터를 환경 변수로 사용하려면 환경 변수를 읽을 수 있는 프로그래밍 언어의 기본 제공 언어 기능을 사용합니다.

예: Python 클라이언트 사용

import os
username = os.getenv("USERNAME")
password = os.getenv("PASSWORD")

주의

바인딩 데이터 디렉터리 이름을 사용하여 바인딩 데이터를 조회하는 경우

Service Binding Operator는 ServiceBinding 리소스 이름(.metadata.name)을 바인딩 데이터 디렉터리 이름으로 사용합니다. 또한 사양에서는 .spec.name 필드를 통해 해당 이름을 재정의하는 방법을 제공합니다. 결과적으로 네임스페이스에 ServiceBinding 리소스가 여러 개인 경우 데이터 이름 충돌을 바인딩할 가능성이 있습니다. 그러나 Kubernetes에서 볼륨 마운트의 특성으로 인해 바인딩 데이터 디렉터리에는 Secret 리소스 중 하나만의 값이 포함됩니다.

6.7.2.1. 바인딩 데이터를 파일로 예상하기 위한 최종 경로 계산

다음 표에는 파일이 특정 디렉터리에 마운트될 때 바인딩 데이터 프로젝션의 최종 경로가 계산되는 방법에 대한 구성이 요약되어 있습니다.

표 6.5. 최종 경로 계산 요약
SERVICE_BINDING_ROOT최종 경로

사용할 수 없음

/bindings/<ServiceBinding_ResourceName>

dir/path/root

dir/path/root/<ServiceBinding_ResourceName>

이전 표에서 < ServiceBinding_ResourceName > 항목은 CR(사용자 정의 리소스)의 .metadata.name 섹션에서 구성하는 ServiceBinding 리소스의 이름을 지정합니다.

참고

기본적으로 예상된 파일에는 0644로 설정된 권한을 가져옵니다. Service Binding Operator는 Kubernetes의 버그로 인해 특정 권한을 설정할 수 없으므로 서비스에 0600 과 같은 특정 권한이 필요한 경우 문제가 발생합니다. 이 문제를 해결하려면 프로그램 코드 또는 워크로드 리소스 내에서 실행 중인 애플리케이션의 코드를 수정하여 파일을 /tmp 디렉터리에 복사하고 적절한 권한을 설정할 수 있습니다.

기존 SERVICE_BINDING_ROOT 환경 변수 내에서 바인딩 데이터에 액세스하고 사용하려면 환경 변수를 읽을 수 있는 프로그래밍 언어의 기본 제공 언어 기능을 사용합니다.

예: Python 클라이언트 사용

from pyservicebinding import binding
try:
    sb = binding.ServiceBinding()
except binding.ServiceBindingRootMissingError as msg:
    # log the error message and retry/exit
    print("SERVICE_BINDING_ROOT env var not set")
sb = binding.ServiceBinding()
bindings_list = sb.bindings("postgresql")

이전 예에서 bindings_list 변수에는 postgresql 데이터베이스 서비스 유형의 바인딩 데이터가 포함되어 있습니다.

6.7.3. 바인딩 데이터 프로젝션

워크로드 요구 사항 및 환경에 따라 바인딩 데이터를 파일 또는 환경 변수로 프로젝트하도록 선택할 수 있습니다.

사전 요구 사항

  • 다음과 같은 개념을 이해할 수 있습니다.

    • 워크로드의 환경 및 요구 사항과 제공된 서비스와의 작동 방식.
    • 워크로드 리소스의 바인딩 데이터 사용
    • 기본 방법에 대해 데이터 프로젝션의 최종 경로를 계산하는 방법 구성
  • 바인딩 데이터는 백업 서비스에서 노출됩니다.

절차

  1. 바인딩 데이터를 파일로 프로젝션하려면 기존 SERVICE_BINDING_ROOT 환경 변수가 워크로드가 실행되는 컨테이너에 있는지 확인하여 대상 폴더를 결정합니다.
  2. 바인딩 데이터를 환경 변수로 프로젝션하려면 CR(사용자 정의 리소스)의 ServiceBinding 리소스에서 .spec.bindAsFiles 매개변수의 값을 false 로 설정합니다.

6.7.4. 추가 리소스

6.8. Service Binding Operator를 사용하여 워크로드 바인딩

애플리케이션 개발자는 바인딩 보안을 사용하여 워크로드를 하나 이상의 백업 서비스에 바인딩해야 합니다. 이 보안은 워크로드에서 사용할 정보를 저장하기 위해 생성됩니다.

예를 들어 연결하려는 서비스가 이미 바인딩 데이터를 노출하는 것을 고려해 보십시오. 이 경우 ServiceBinding CR(사용자 정의 리소스)과 함께 사용할 워크로드도 필요합니다. 이 ServiceBinding CR을 사용하면 워크로드에서 바인딩할 서비스의 세부 정보와 함께 바인딩 요청을 보냅니다.

ServiceBinding CR의 예

apiVersion: binding.operators.coreos.com/v1alpha1
kind: ServiceBinding
metadata:
    name: spring-petclinic-pgcluster
    namespace: my-petclinic
spec:
    services: 1
    - group: postgres-operator.crunchydata.com
      version: v1beta1
      kind: PostgresCluster
      name: hippo
    application: 2
      name: spring-petclinic
      group: apps
      version: v1
      resource: deployments

1
서비스 리소스 목록을 지정합니다.
2
포함된 PodSpec을 사용하여 배포 또는 기타 유사한 리소스를 가리키는 샘플 애플리케이션입니다.

이전 예에 표시된 대로 ConfigMap 또는 Secret 자체를 바인딩 데이터 소스로 사용할 서비스 리소스로 직접 사용할 수도 있습니다.

6.8.1. 이름 지정 전략

이름 지정 전략은 binding.operators.coreos.com API 그룹에만 사용할 수 있습니다.

이름 지정 전략에서는 Go 템플릿을 사용하여 서비스 바인딩 요청을 통해 사용자 지정 바인딩 이름을 정의하는 데 도움이 됩니다. 이름 지정 전략은 ServiceBinding CR(사용자 정의 리소스)의 매핑을 포함하여 모든 속성에 적용됩니다.

지원 서비스 프로젝트는 이름을 워크로드에 파일 또는 환경 변수로 바인딩합니다. 워크로드에 특정 형식으로 예상 바인딩 이름이 예상되지만 백업 서비스에서 예상하는 바인딩 이름을 해당 형식으로 사용할 수 없는 경우 이름 지정 전략을 사용하여 바인딩 이름을 변경할 수 있습니다.

사전 정의된 후 처리 함수

워크로드의 기대치 또는 요구 사항에 따라 이름 지정 전략을 사용하는 동안 임의의 조합에서 다음과 같은 사전 정의된 후 처리 함수를 사용하여 문자 문자열을 변환할 수 있습니다.

  • upper: 문자 문자열을 대문자 또는 대문자로 변환합니다.
  • lower: 문자 문자열을 소문자로 변환합니다.
  • 특정 마이너 단어를 제외한 각 단어의 첫 번째 문자가 대문자로 지정된 문자 문자열을 변환합니다.

사전 정의된 이름 지정 전략

주석을 통해 선언된 바인딩 이름은 다음과 같은 사전 정의된 이름 지정 설정에 따라 프로젝션에 따라 워크로드로의 예상 전에 이름 변경을 위해 처리됩니다.

  • None: 적용된 경우 바인딩 이름에 변경 사항이 없습니다.

    예제

    템플릿 컴파일 후 바인딩 이름은 {{ .name }} 양식을 사용합니다.

    host: hippo-pgbouncer
    port: 5432
  • upper: namingStrategy 가 정의되지 않은 경우 적용됩니다. 적용되는 경우 바인딩 이름 키의 모든 문자 문자열을 대문자 또는 대문자로 변환합니다.

    예제

    템플릿 컴파일 후 바인딩 이름은 {{ .service.kind | upper}}_{{ .name | upper }} 양식을 사용합니다.

    DATABASE_HOST: hippo-pgbouncer
    DATABASE_PORT: 5432

    워크로드에 다른 형식이 필요한 경우 사용자 지정 이름 지정 전략을 정의하고 접두사 및 구분자(예: PORT_DATABASE )를 사용하여 바인딩 이름을 변경할 수 있습니다.

참고
  • 바인딩 이름이 파일로 프로젝션되면 기본적으로 사전 정의된 none 이름 지정 전략이 적용되고 바인딩 이름은 변경되지 않습니다.
  • 바인딩 이름이 환경 변수로 프로젝션되고 namingStrategy 가 정의되지 않은 경우 기본적으로 사전 정의된 대문자 이름 지정 전략이 적용됩니다.
  • 사용자 지정 바인딩 이름 및 사전 정의된 후 처리 함수의 다양한 조합을 사용하여 사용자 지정 이름 지정 전략을 정의하여 사전 정의된 이름 지정 전략을 재정의할 수 있습니다.

6.8.2. 고급 바인딩 옵션

ServiceBinding CR(사용자 정의 리소스)을 정의하여 다음과 같은 고급 바인딩 옵션을 사용할 수 있습니다.

  • 바인딩 이름 변경: 이 옵션은 binding.operators.coreos.com API 그룹에만 사용할 수 있습니다.
  • 사용자 지정 바인딩 데이터 컴파일: 이 옵션은 binding.operators.coreos.com API 그룹에만 사용할 수 있습니다.
  • 라벨 선택기를 사용하여 워크로드를 바인딩: 이 옵션은 binding.operators.coreos.comservicebinding.io API 그룹 모두에서 사용할 수 있습니다.
6.8.2.1. 워크로드에 프로젝트를 수행하기 전에 바인딩 이름 변경

ServiceBinding CR의 .spec.namingStrategy 특성에서 바인딩 이름을 변경하는 규칙을 지정할 수 있습니다. 예를 들어 PostgreSQL 데이터베이스에 연결된 Spring PetClinic 샘플 애플리케이션을 고려해 보십시오. 이 경우 PostgreSQL 데이터베이스 서비스는 바인딩에 사용할 데이터베이스의 호스트포트 필드를 노출합니다. Spring PetClinic 샘플 애플리케이션은 바인딩 이름을 통해 이러한 노출된 바인딩 데이터에 액세스할 수 있습니다.

예: ServiceBinding CR의 Spring PetClinic 샘플 애플리케이션

# ...
    application:
      name: spring-petclinic
      group: apps
      version: v1
      resource: deployments
# ...

예: ServiceBinding CR의 PostgreSQL 데이터베이스 서비스

# ...
    services:
    - group: postgres-operator.crunchydata.com
      version: v1beta1
      kind: PostgresCluster
      name: hippo
# ...

namingStrategy 가 정의되어 있지 않고 바인딩 이름이 환경 변수로 프로젝션되면 지원 서비스의 hippo-pgbouncer 값이 다음 예와 같이 표시됩니다.

예제

DATABASE_HOST: hippo-pgbouncer

다음과 같습니다.

데이터베이스

kind 백엔드 서비스를 지정합니다.

HOST

바인딩 이름을 지정합니다.

POSTGRESQL_{{ .service.kind | 상한 }}_{{ .name | 상한 }}_ENV 이름 지정 전략을 적용한 후 서비스 바인딩 요청에 의해 준비된 사용자 정의 바인딩 이름 목록이 다음 예와 같이 표시됩니다.

예제

POSTGRESQL_DATABASE_HOST_ENV: hippo-pgbouncer
POSTGRESQL_DATABASE_PORT_ENV: 5432

다음 항목에서는 POSTGRESQL_{{.service.kind | upper }}_{{ .name | 상한 }}_ENV 이름 지정 전략에 정의된 표현식을 설명합니다.

  • .name: 백업 서비스에서 노출하는 바인딩 이름을 참조합니다. 이전 예에서 바인딩 이름은 HOSTPORT 입니다.
  • .service.kind: 이름 지정 전략을 사용하여 바인딩 이름이 변경된 서비스 리소스를 나타냅니다.
  • upper: Go 템플릿 문자열을 컴파일하는 동안 문자 문자열을 post-process하는 데 사용되는 문자열 함수입니다.
  • POSTGRESQL: 사용자 지정 바인딩 이름의 접두사입니다.
  • ENV: 사용자 지정 바인딩 이름의 Suffix입니다.

이전 예제와 유사하게 namingStrategy 에서 문자열 템플릿을 정의하여 서비스 바인딩 요청에서 바인딩 이름의 각 키를 준비하는 방법을 정의할 수 있습니다.

6.8.2.2. 사용자 정의 바인딩 데이터 작성

애플리케이션 개발자는 다음과 같은 상황에서 사용자 지정 바인딩 데이터를 작성할 수 있습니다.

  • 백업 서비스는 바인딩 데이터를 노출하지 않습니다.
  • 노출된 값은 워크로드에서 예상대로 필수 형식으로 사용할 수 없습니다.

예를 들어 백업 서비스 CR에서 호스트, 포트 및 데이터베이스 사용자를 바인딩 데이터로 노출하는 경우를 고려해 보십시오. 그러나 워크로드에서 바인딩 데이터를 연결 문자열로 사용해야 합니다. 백업 서비스를 나타내는 Kubernetes 리소스의 속성을 사용하여 사용자 정의 바인딩 데이터를 작성할 수 있습니다.

예제

apiVersion: binding.operators.coreos.com/v1alpha1
kind: ServiceBinding
metadata:
    name: spring-petclinic-pgcluster
    namespace: my-petclinic
spec:
    services:
    - group: postgres-operator.crunchydata.com
      version: v1beta1
      kind: PostgresCluster
      name: hippo 1
      id: postgresDB 2
    - group: ""
      version: v1
      kind: Secret
      name: hippo-pguser-hippo
      id: postgresSecret
    application:
      name: spring-petclinic
      group: apps
      version: v1
      resource: deployments
    mappings:
      ## From the database service
      - name: JDBC_URL
        value: 'jdbc:postgresql://{{ .postgresDB.metadata.annotations.proxy }}:{{ .postgresDB.spec.port }}/{{ .postgresDB.metadata.name }}'
      ## From both the services!
      - name: CREDENTIALS
        value: '{{ .postgresDB.metadata.name }}{{ translationService.postgresSecret.data.password }}'
      ## Generate JSON
      - name: DB_JSON 3
        value: {{ json .postgresDB.status }} 4

1
백업 서비스 리소스의 이름입니다.
2
선택적 식별자입니다.
3
Service Binding Operator가 생성하는 JSON 이름입니다. Service Binding Operator는 이 JSON 이름을 파일 또는 환경 변수의 이름으로 프로젝트합니다.
4
Service Binding Operator가 생성하는 JSON 값입니다. Service Binding Operator는 이 JSON 값을 파일 또는 환경 변수로 프로젝트합니다. JSON 값에는 백업 서비스 사용자 정의 리소스의 지정된 필드의 속성이 포함됩니다.
6.8.2.3. 라벨 선택기를 사용하여 워크로드 바인딩

레이블 선택기를 사용하여 바인딩할 워크로드를 지정할 수 있습니다. 라벨 선택기를 사용하여 워크로드를 가져온 서비스 바인딩을 선언하면 Service Binding Operator는 지정된 라벨 선택기와 일치하는 새 워크로드를 주기적으로 찾아 바인딩합니다.

예를 들어 클러스터 관리자는 ServiceBinding CR에서 적절한 labelSelector 필드를 설정하여 environment: production 라벨이 있는 네임스페이스의 모든 배포에 서비스를 바인딩할 수 있습니다. 이를 통해 Service Binding Operator는 이러한 각 워크로드를 하나의 ServiceBinding CR에 바인딩할 수 있습니다.

binding.operators.coreos.com/v1alpha1 API의 ServiceBinding CR의 예

apiVersion: binding.operators.coreos.com/v1alpha1
kind: ServiceBinding
metadata:
  name: multi-application-binding
  namespace: service-binding-demo
spec:
  application:
    labelSelector: 1
      matchLabels:
        environment: production
    group: apps
    version: v1
    resource: deployments
  services:
    group: ""
    version: v1
    kind: Secret
    name: super-secret-data

1
바인딩되는 워크로드를 지정합니다.

servicebinding.io API의 ServiceBinding CR의 예

apiVersion: servicebindings.io/v1beta1
kind: ServiceBinding
metadata:
  name: multi-application-binding
  namespace: service-binding-demo
spec:
  workload:
    selector: 1
      matchLabels:
        environment: production
    apiVersion: app/v1
    kind: Deployment
  service:
    apiVersion: v1
    kind: Secret
    name: super-secret-data

1
바인딩되는 워크로드를 지정합니다.
중요

다음 필드 쌍을 정의하는 경우 Service Binding Operator는 바인딩 작업을 거부하고 오류를 생성합니다.

  • binding.operators.coreos.com/v1alpha1 API의 namelabelSelector 필드입니다.
  • servicebinding.io API(Spec API)의 nameselector 필드입니다.

rebinding 동작 이해

성공적으로 바인딩한 후 name 필드를 사용하여 워크로드를 식별하는 경우를 고려하십시오. 해당 워크로드를 삭제하고 재생성하면 ServiceBinding 조정기에서 워크로드를 다시 바인딩하지 않으며 Operator는 바인딩 데이터를 워크로드에 프로젝션할 수 없습니다. 그러나 labelSelector 필드를 사용하여 워크로드를 식별하는 경우 ServiceBinding 조정기에서 워크로드를 다시 바인딩하고 Operator에서 바인딩 데이터를 프로젝트합니다.

6.8.3. PodSpec을 준수하지 않는 보조 워크로드 바인딩

서비스 바인딩의 일반적인 시나리오에는 백업 서비스, 워크로드(배포) 및 Service Binding Operator를 구성해야 합니다. PodSpec을 준수하지 않고 기본 워크로드(Deployment)와 Service Binding Operator 사이에 있는 보조 워크로드(애플리케이션 Operator일 수도 있음)가 포함된 시나리오를 고려하십시오.

이러한 보조 워크로드 리소스의 경우 컨테이너 경로의 위치가 임의로 사용됩니다. 서비스 바인딩의 경우 CR의 보조 워크로드가 PodSpec과 호환되지 않는 경우 컨테이너 경로의 위치를 지정해야 합니다. 이렇게 하면 Pod 내부의 바인딩 데이터를 원하지 않는 경우와 같이 ServiceBinding CR(사용자 정의 리소스)의 보조 워크로드에 지정된 컨테이너 경로에 바인딩 데이터를 프로젝트합니다.

Service Binding Operator에서는 워크로드 내에 컨테이너 또는 보안이 있는 위치 경로를 구성하고 사용자 지정 위치에서 이러한 경로를 바인딩할 수 있습니다.

6.8.3.1. 컨테이너 경로의 사용자 지정 위치 구성

Service Binding Operator가 바인딩 데이터를 환경 변수로 프로젝트할 때 바인딩.operators.coreos.com API group에 이 사용자 지정 위치를 사용할 수 있습니다.

보조 워크로드 CR을 고려해 보십시오. 이 CR은 PodSpec과 사양.containers 경로에 있는 컨테이너가 있습니다.

예: 보조 워크로드 CR

apiVersion: "operator.sbo.com/v1"
kind: SecondaryWorkload
metadata:
    name: secondary-workload
spec:
    containers:
    - name: hello-world
      image: quay.io/baijum/secondary-workload:latest
      ports:
      - containerPort: 8080

절차

  • ServiceBinding CR에 값을 지정하고 이 경로를 spec.application.bindingPath.containersPath 사용자 지정 위치에 바인딩하여 spec.containers 경로를 구성합니다.

    예: 사용자 정의 위치의 spec.containers 경로가 있는 ServiceBinding CR

    apiVersion: binding.operators.coreos.com/v1alpha1
    kind: ServiceBinding
    metadata:
        name: spring-petclinic-pgcluster
    spec:
        services:
        - group: postgres-operator.crunchydata.com
          version: v1beta1
          kind: PostgresCluster
          name: hippo
          id: postgresDB
        - group: ""
          version: v1
          kind: Secret
          name: hippo-pguser-hippo
          id: postgresSecret
        application: 1
          name: spring-petclinic
          group: apps
          version: v1
          resource: deployments
        application: 2
          name: secondary-workload
          group: operator.sbo.com
          version: v1
          resource: secondaryworkloads
          bindingPath:
            containersPath: spec.containers 3

    1
    포함된 PodSpec을 사용하여 배포 또는 기타 유사한 리소스를 가리키는 샘플 애플리케이션입니다.
    2
    보조 워크로드: PodSpec을 준수하지 않습니다.
    3
    컨테이너 경로의 사용자 지정 위치입니다.

컨테이너 경로의 위치를 지정하면 Service Binding Operator가 바인딩 데이터를 생성하여 ServiceBinding CR의 보조 워크로드에 지정된 컨테이너 경로에서 사용할 수 있게 됩니다.

다음 예제에서는 envFromsecretRef 필드가 있는 spec.containers 경로를 보여줍니다.

예: envFromsecretRef 필드가 있는 보조 워크로드 CR

apiVersion: "operator.sbo.com/v1"
kind: SecondaryWorkload
metadata:
    name: secondary-workload
spec:
    containers:
    - env: 1
      - name: ServiceBindingOperatorChangeTriggerEnvVar
        value: "31793"
      envFrom:
      - secretRef:
          name: secret-resource-name 2
      image: quay.io/baijum/secondary-workload:latest
      name: hello-world
      ports:
      - containerPort: 8080
      resources: {}

1
Service Binding Operator에서 생성한 값이 있는 컨테이너의 고유 배열입니다. 이러한 값은 백업 서비스 CR을 기반으로 합니다.
2
Service Binding Operator에서 생성한 Secret 리소스의 이름입니다.
6.8.3.2. 보안 경로의 사용자 정의 위치 구성

Service Binding Operator가 바인딩 데이터를 환경 변수로 프로젝트할 때 바인딩.operators.coreos.com API group에 이 사용자 지정 위치를 사용할 수 있습니다.

spec.secret 경로의 보안만 있는 PodSpec과 호환되지 않는 보조 워크로드 CR을 고려하십시오.

예: 보조 워크로드 CR

apiVersion: "operator.sbo.com/v1"
kind: SecondaryWorkload
metadata:
    name: secondary-workload
spec:
    secret: ""

절차

  • ServiceBinding CR에 값을 지정하고 spec.application.bindingPath.secretPath 사용자 정의 위치에 이 경로를 바인딩하여 spec.secret 경로를 구성합니다.

    예: 사용자 정의 위치의 spec.secret 경로가 있는 ServiceBinding CR

    apiVersion: binding.operators.coreos.com/v1alpha1
    kind: ServiceBinding
    metadata:
        name: spring-petclinic-pgcluster
    spec:
    ...
        application: 1
          name: secondary-workload
          group: operator.sbo.com
          version: v1
          resource: secondaryworkloads
          bindingPath:
            secretPath: spec.secret 2
    ...

    1
    보조 워크로드: PodSpec을 준수하지 않습니다.
    2
    Secret 리소스의 이름이 포함된 보안 경로의 사용자 정의 위치입니다.

보안 경로의 위치를 지정하면 Service Binding Operator는 바인딩 데이터를 생성하여 ServiceBinding CR의 보조 워크로드에 지정된 보안 경로에서 사용할 수 있게 됩니다.

다음 예제에서는 binding-request 값이 있는 spec.secret 경로를 보여줍니다.

예: binding-request 값을 사용하는 보조 워크로드 CR

...
apiVersion: "operator.sbo.com/v1"
kind: SecondaryWorkload
metadata:
    name: secondary-workload
spec:
    secret: binding-request-72ddc0c540ab3a290e138726940591debf14c581 1
...

1
Service Binding Operator가 생성하는 Secret 리소스의 고유 이름입니다.
6.8.3.3. 워크로드 리소스 매핑
참고
  • 워크로드 리소스 매핑은 API 그룹 binding.operators.coreos.comservicebinding.io 에 대해 ServiceBinding CR(사용자 정의 리소스)의 보조 워크로드에 사용할 수 있습니다.
  • servicebinding.io API 그룹에서만 ClusterWorkloadResourceMapping 리소스를 정의해야 합니다. 그러나 ClusterWorkloadResourceMapping 리소스는 binding.operators.coreos.comservicebinding.io API 그룹 모두에서 ServiceBinding 리소스와 상호 작용합니다.

컨테이너 경로에 구성 방법을 사용하여 사용자 정의 경로 위치를 구성할 수 없는 경우 바인딩 데이터를 예상해야 하는 위치를 정확하게 정의할 수 있습니다. servicebinding.io API 그룹에서 ClusterWorkloadResourceMapping 리소스를 정의하여 지정된 워크로드에 대한 바인딩 데이터를 프로젝트할 위치를 지정합니다.

다음 예제에서는 CronJob.knativech/v1 리소스에 대한 매핑을 정의하는 방법을 보여줍니다.

예: CronJob.knativech/v1 리소스 매핑

apiVersion: servicebinding.io/v1beta1
kind: ClusterWorkloadResourceMapping
metadata:
 name: cronjobs.batch 1
spec:
  versions:
  - version: "v1" 2
    annotations: .spec.jobTemplate.spec.template.metadata.annotations 3
    containers:
    - path: .spec.jobTemplate.spec.template.spec.containers[*] 4
    - path: .spec.jobTemplate.spec.template.spec.initContainers[*]
      name: .name 5
      env: .env 6
      volumeMounts: .volumeMounts 7
    volumes: .spec.jobTemplate.spec.template.spec.volumes 8

1
매핑된 워크로드 리소스의 plural.group 으로 자격을 부여해야 하는 ClusterWorkloadResourceMapping 리소스의 이름입니다.
2
매핑되는 리소스의 버전입니다. 지정되지 않은 버전은 "*" 와일드카드와 일치할 수 있습니다.
3
선택 사항: 고정된 JSONPath로 지정된 Pod의 .annotations 필드의 식별자입니다. 기본값은 .spec.template.spec.annotations 입니다.
4
Pod의 .containers.initContainers 필드의 식별자로 JSONPath로 지정됩니다. containers 필드에 항목이 정의되지 않은 경우 Service Binding Operator의 기본값은 .spec.template.spec.containers[*].spec.template.spec.initContainers[\*] 이며 다른 모든 필드는 기본값으로 설정됩니다. 그러나 항목을 지정하는 경우 .path 필드를 정의해야 합니다.
5
선택 사항: 고정된 JSONPath로 지정된 컨테이너의 .name 필드의 식별자입니다. 기본값은 .name 입니다.
6
선택 사항: 고정된 JSONPath로 지정된 컨테이너의 .env 필드의 식별자입니다. 기본값은 .env 입니다.
7
선택 사항: 고정된 JSONPath로 지정된 컨테이너의 .volumeMounts 필드의 식별자입니다. 기본값은 .volumeMounts 입니다.
8
선택 사항: 고정된 JSONPath로 지정된 Pod의 .volumes 필드의 식별자입니다. 기본값은 .spec.template.spec.volumes 입니다.
중요
  • 이 컨텍스트에서 고정된 JSONPath는 다음 작업만 허용하는 JSONPath grammar의 서브 세트입니다.

    • 필드 조회: .spec.template
    • 배열 인덱싱: .spec['template']

    다른 모든 작업은 허용되지 않습니다.

  • 이러한 필드의 대부분은 선택 사항입니다. 지정하지 않으면 Service Binding Operator는 PodSpec 리소스와 호환되는 기본값을 가정합니다.
  • Service Binding Operator를 사용하려면 이러한 각 필드가 Pod 배포의 해당 필드와 구조적으로 같아야 합니다. 예를 들어 워크로드 리소스의 .env 필드의 콘텐츠는 Pod 리소스의 .env 필드와 동일한 데이터 구조를 허용할 수 있어야 합니다. 그렇지 않으면 이러한 워크로드에 바인딩 데이터를 예상하면 Service Binding Operator에서 예기치 않은 동작이 발생할 수 있습니다.

binding.operators.coreos.com API 그룹과 관련된 동작

ClusterWorkloadResourceMapping 리소스가 binding.operators.coreos.com API 그룹에서 ServiceBinding 리소스와 상호 작용할 때 다음 동작을 기대할 수 있습니다.

  • bindAsFiles: false 플래그 값이 있는 ServiceBinding 리소스가 이러한 매핑 중 하나와 함께 생성되는 경우 해당 ClusterWorkloadResourceMapping 리소스에 지정된 각 경로 필드 아래의 .envFrom 필드에 환경 변수가 projected됩니다.
  • 클러스터 관리자는 바인딩 목적으로 ServiceBinding.bindings.coreos.com 리소스에서 ClusterWorkloadResourceMapping 리소스와 .spec.application.bindingPath.containersPath 필드를 모두 지정할 수 있습니다.

    Service Binding Operator는 ClusterWorkloadResourceMapping 리소스와 .spec.application.bindingPath.containersPath 필드 모두에 지정된 위치에 데이터를 바인딩하려고 합니다. 이 동작은 path: $containersPath 특성과 함께 기본값을 사용하는 기타 모든 값과 함께 해당 ClusterWorkloadResourceMapping 리소스에 컨테이너 항목을 추가하는 것과 동일합니다.

6.8.4. 백업 서비스에서 워크로드 바인딩 해제

oc 툴을 사용하여 백업 서비스에서 워크로드를 바인딩 해제할 수 있습니다.

  • 백업 서비스에서 워크로드를 바인딩 해제하려면 연결된 ServiceBinding CR(사용자 정의 리소스)을 삭제합니다.

    $ oc delete ServiceBinding <.metadata.name>

    예제

    $ oc delete ServiceBinding spring-petclinic-pgcluster

    다음과 같습니다.

    spring-petclinic-pgcluster

    ServiceBinding CR의 이름을 지정합니다.

6.8.5. 추가 리소스

6.9. 개발자 화면을 사용하여 서비스에 애플리케이션 연결

다음과 같은 목적으로 토폴로지 보기를 사용합니다.

  • 애플리케이션 내에서 여러 구성 요소를 그룹화합니다.
  • 구성 요소를 서로 연결합니다.
  • 라벨을 사용하여 서비스에 여러 리소스 연결.

바인딩 또는 시각적 커넥터를 사용하여 구성 요소를 연결할 수 있습니다.

대상 노드가 Operator 지원 서비스인 경우에만 구성 요소 간 바인딩 연결을 설정할 수 있습니다. 이러한 연결은 해당 대상 노드로 화살표를 드래그할 때 표시되는 바인딩 커넥터 생성 툴팁으로 표시됩니다. 바인딩 커넥터를 사용하여 애플리케이션을 서비스에 연결하면 ServiceBinding 리소스가 생성됩니다. 그런 다음 Service Binding Operator 컨트롤러에서 필요한 바인딩 데이터를 애플리케이션 배포에 프로젝트합니다. 요청이 성공하면 애플리케이션이 재배포되어 연결된 구성 요소 간 상호 작용을 설정합니다.

시각적 커넥터는 구성 요소 간 시각적 연결만 설정하고 연결하려는 의도를 표시합니다. 구성 요소 간 상호 작용은 설정되지 않습니다. 대상 노드가 Operator에서 지원하는 서비스가 아닌 경우 대상 노드로 화살표를 드래그하면 시각적 커넥터 생성 툴팁이 표시됩니다.

6.9.1. Operator 지원 바인딩 서비스 검색 및 확인

사용자는 바인딩 가능한 서비스를 생성하려면 어떤 서비스를 바인딩할 수 있는지 알아야 합니다. 바인딩 가능한 서비스는 자격 증명, 연결 세부 정보, 볼륨 마운트, 시크릿 및 기타 바인딩 데이터와 같은 바인딩 데이터를 표준 방식으로 노출하기 때문에 애플리케이션이 쉽게 사용할 수 있는 서비스입니다. Developer 관점은 이러한 바인딩 가능한 서비스를 검색하고 식별하는 데 도움이 됩니다.

절차

  • Operator에서 지원하는 바인딩 서비스를 검색하고 확인하려면 다음과 같은 대체 방법을 고려하십시오.

    • +추가개발자 카탈로그Operator Backed 를 클릭하여 Operator가 지원하는 것을 확인합니다. 서비스 바인딩 기능을 지원하는 Operator 지원 서비스에는 바인딩 가능한 배지가 있습니다.
    • Operator Backed 페이지의 왼쪽 창에서 바인딩 가능 을 선택합니다.

      작은 정보

      서비스 바인딩 옆에 있는 도움말 아이콘을 클릭하여 바인딩 가능한 서비스에 대한 자세한 정보를 확인합니다.

    • +추가추가를 클릭하고 Operator 지원 서비스를 검색합니다. 바인딩 가능한 서비스를 클릭하면 측면 패널에서 바인딩 가능한 배지 를 볼 수 있습니다.

6.9.2. 구성 요소 간 시각적 연결 생성

시각적 커넥터를 사용하여 애플리케이션 구성 요소를 연결하려는 의도를 나타낼 수 있습니다.

이 절차에서는 PostgreSQL 데이터베이스 서비스와 Spring PetClinic 샘플 애플리케이션 간 시각적 연결을 생성하는 예를 보여줍니다.

사전 요구 사항

  • 개발자 화면을 사용하여 Spring PetClinic 샘플 애플리케이션을 생성하고 배포했습니다.
  • 개발자 화면을 사용하여 Crunchy PostgreSQL 데이터베이스 인스턴스를 생성하고 배포했습니다. 이 인스턴스에는 hippo-backup,hippo-instance,hippo-repo-host, hippo-pgbouncer 의 구성 요소가 있습니다.

절차

  1. 개발자 관점에서 관련 프로젝트로 전환합니다(예: my-petclinic ).
  2. Spring PetClinic 샘플 애플리케이션 위에 커서를 이동하여 노드에서 실행 중인 화살표를 확인합니다.

    그림 6.2. 시각적 커넥터

    odc connector
  3. 화살표를 클릭하고 hippo-pgbouncer 배포로 드래그하여 Spring PetClinic 샘플 애플리케이션을 연결합니다.
  4. spring-petclinic 배포를 클릭하여 개요 패널을 확인합니다. 세부 정보 탭 아래의 주석 섹션의 편집 아이콘을 클릭하여 배포에 추가된 Key = app.openshift.io/connects-toValue = [{"apiVersion":"apps/v1","kind":"Deployment","name":"hippo-pgbouncer"}] 주석을 확인합니다.
  5. 선택 사항: 이러한 단계를 반복하여 생성한 다른 애플리케이션과 구성 요소 간에 시각적 연결을 설정할 수 있습니다.

    그림 6.3. 여러 애플리케이션 연결

    여러 애플리케이션을 연결하는 odc 연결

6.9.3. 구성 요소 간 바인딩 연결 생성

PostgreSQL 데이터베이스 서비스 및 Spring PetClinic 샘플 애플리케이션을 사용하는 다음 예에 설명된 대로 Operator 지원 구성 요소를 사용하여 바인딩 연결을 생성할 수 있습니다. PostgreSQL Database Operator가 지원하는 서비스로 바인딩 연결을 생성하려면 먼저 Red Hat 제공 PostgreSQL Database Operator를 OperatorHub 에 추가한 다음 Operator를 설치해야 합니다. 그런 다음 PostreSQL Database Operator는 시크릿, 구성 맵, 상태 및 사양 속성에 바인딩 데이터를 노출하는 데이터베이스 리소스를 생성하고 관리합니다.

사전 요구 사항

  • 개발자 화면에 Spring PetClinic 샘플 애플리케이션을 생성하고 배포했습니다.
  • OperatorHub 에서 Service Binding Operator를 설치했습니다.
  • v5 업데이트 채널의 OperatorHub에서 Kubernetes Operator에 대한 Crunchy Postgres 를 설치하셨습니다.
  • 개발자 화면에 PostgresCluster 리소스를 생성했으므로 hippo-backup,hippo-instance,hippo-repo-host, hippo-pgbouncer 의 구성 요소를 사용하여 Crunchy PostgreSQL 데이터베이스 인스턴스가 생성되었습니다.

절차

  1. 개발자 관점에서 관련 프로젝트로 전환합니다(예: my-petclinic ).
  2. 토폴로지 보기에서 Spring PetClinic 샘플 애플리케이션 위에 커서를 이동하여 노드에서 분리된 화살표를 확인합니다.
  3. Spring PetClinic 샘플 애플리케이션과 바인딩하기 위해 Postgres 클러스터의 hippo 데이터베이스 아이콘으로 화살표를 드래그 앤 드롭합니다.
  4. 서비스 바인딩 생성 대화 상자에서 기본 이름을 유지하거나 서비스 바인딩에 대한 다른 이름을 추가한 다음 만들기를 클릭합니다.

    그림 6.4. 서비스 바인딩 대화 상자

    odc sbc modal
  5. 선택 사항: 토폴로지 보기를 사용하여 바인딩 연결을 수행하는 데 어려움이 있는 경우 +추가YAMLYAML 가져오기 로 이동합니다.
  6. 선택 사항: YAML 편집기에서 ServiceBinding 리소스를 추가합니다.

    apiVersion: binding.operators.coreos.com/v1alpha1
    kind: ServiceBinding
    metadata:
        name: spring-petclinic-pgcluster
        namespace: my-petclinic
    spec:
        services:
        - group: postgres-operator.crunchydata.com
          version: v1beta1
          kind: PostgresCluster
          name: hippo
        application:
          name: spring-petclinic
          group: apps
          version: v1
          resource: deployments

    서비스 바인딩 요청이 생성되고 바인딩 연결이 ServiceBinding 리소스를 통해 생성됩니다. 데이터베이스 서비스 연결 요청이 성공하면 애플리케이션이 재배포되고 연결이 설정됩니다.

    그림 6.5. 바인딩 커넥터

    odc binding connector
    작은 정보

    dangling 화살표를 드래그하여 Operator 지원 서비스에 바인딩 연결을 추가하고 만들어 컨텍스트 메뉴를 사용할 수도 있습니다.

    그림 6.6. 바인딩 연결을 생성하는 컨텍스트 메뉴

    odc context operator
  7. 탐색 메뉴에서 토폴로지 를 클릭합니다. Topology 뷰의 Spring-petclinic 배포에는 웹 페이지를 볼 수 있는 Open URL 링크가 포함되어 있습니다.
  8. Open URL 링크를 클릭합니다.

이제 Spring PetClinic 샘플 애플리케이션을 원격으로 보고 애플리케이션이 현재 데이터베이스 서비스에 연결되었고 데이터가 Crunchy PostgreSQL 데이터베이스 서비스에서 애플리케이션에 성공적으로 프로젝션되었는지 확인할 수 있습니다.

Service Binding Operator가 애플리케이션과 데이터베이스 서비스 간의 작업 연결을 성공적으로 생성했습니다.

6.9.4. 토폴로지 보기에서 서비스 바인딩 상태 확인

개발자 화면을 사용하면 토폴로지 보기를 통해 서비스 바인딩 상태를 확인할 수 있습니다.

절차

  1. 서비스 바인딩에 성공한 경우 바인딩 커넥터를 클릭합니다. 세부 정보 탭에 연결된 상태를 표시하는 측면 패널이 나타납니다.

    필요한 경우 개발자 화면에서 다음 페이지에서 연결된 상태를 볼 수 있습니다.

    • ServiceBindings 페이지입니다.
    • ServiceBinding 세부 정보 페이지. 또한 페이지 제목에 연결된 배지가 표시됩니다.
  2. 서비스 바인딩에 실패한 경우 바인딩 커넥터에 연결 중간에 빨간색 화살표 헤드와 빨간색 교차가 표시됩니다. 이 커넥터를 클릭하여 세부 정보 탭의 측면 패널에서 Error 상태를 확인합니다. 필요한 경우 오류 상태를 클릭하여 근본적인 문제에 대한 특정 정보를 봅니다.

    개발자 화면에서 다음 페이지에서 Error 상태와 툴팁을 볼 수도 있습니다.

    • ServiceBindings 페이지입니다.
    • ServiceBinding 세부 정보 페이지. 또한 페이지 제목에 오류 배지가 표시됩니다.
작은 정보

ServiceBindings 페이지에서 필터 드롭다운을 사용하여 상태에 따라 서비스 바인딩을 나열합니다.

6.9.5. 리소스에 대한 바인딩 연결 시각화

사용자로 Topology 보기에서 Label Selector 를 사용하여 서비스 바인딩을 시각화하고 서비스를 지원하기 위해 애플리케이션을 바인딩하는 프로세스를 단순화합니다. ServiceBinding 리소스를 생성할 때 Label Selector 를 사용하여 애플리케이션 이름을 사용하는 대신 애플리케이션을 찾고 연결함으로써 라벨을 지정합니다. 그러면 Service Binding Operator에서 이러한 ServiceBinding 리소스 및 지정된 레이블을 사용하여 서비스 바인딩을 생성하는 애플리케이션을 찾습니다.

작은 정보

연결된 모든 리소스 목록으로 이동하려면 ServiceBinding 리소스와 연결된 라벨 선택기를 클릭합니다.

라벨 선택기 를 보려면 다음 방법을 고려하십시오.

  • ServiceBinding 리소스를 가져온 후 ServiceBinding 세부 정보 페이지에서 서비스 바인딩과 연결된 Label Selector 를 확인합니다.

    그림 6.7. ServiceBinding 세부 정보 페이지

    odc label selector sb 세부 정보
참고

Label Selector 를 사용하고 한 번에 하나 이상의 연결을 생성하려면 ServiceBinding 리소스의 YAML 파일을 가져와야 합니다.

  • 연결이 설정되고 바인딩 커넥터를 클릭하면 서비스 바인딩 커넥터 세부 정보 측면 패널이 표시됩니다. 이 패널의 서비스 바인딩과 관련된 라벨 Selector 를 볼 수 있습니다.

    그림 6.8. 토폴로지 라벨 선택기 측면 패널

    odc label selector topology side panel
    참고

    바인딩 커넥터(서비스 바인딩과 함께 토폴로지 내 단일 연결)를 삭제하면 삭제된 서비스 바인딩에 연결된 모든 연결이 제거됩니다. 바인딩 커넥터를 삭제하는 동안 모든 커넥터가 삭제되도록 알리는 확인 대화 상자가 표시됩니다.

    그림 6.9. ServiceBinding 확인 대화 상자 삭제

    odc delete service binding

6.9.6. 추가 리소스

7장. Helm 차트 작업

7.1. Helm 이해

Helm은 OpenShift Container Platform 클러스터에 대한 애플리케이션 및 서비스 배포를 간소화하는 소프트웨어 패키지 관리자입니다.

Helm은 차트라는 패키징 형식을 사용합니다. Helm 차트는 OpenShift Container Platform 리소스에 대해 설명하는 파일 컬렉션입니다.

클러스터에서 차트를 생성하면 릴리스 라는 차트의 실행 중인 인스턴스가 생성됩니다.

차트가 생성되거나 릴리스가 업그레이드되거나 롤백될 때마다 리버전이 생성됩니다.

7.1.1. 주요 기능

Helm은 다음을 수행할 수 있는 기능을 제공합니다.

  • 차트 리포지토리에 저장된 대규모 차트 컬렉션에서 검색합니다.
  • 기존 차트를 수정합니다.
  • OpenShift Container Platform 또는 Kubernetes 리소스를 사용하여 자체 차트를 생성합니다.
  • 애플리케이션을 차트로 패키징하고 공유합니다.

7.1.2. OpenShift용 Red Hat Helm 차트 인증

Red Hat OpenShift Container Platform에 배포할 모든 구성 요소에 대해 Red Hat에서 Helm 차트를 검증하고 인증할 수 있습니다. 차트는 보안 규정 준수뿐만 아니라 플랫폼 관련 최상의 통합 및 환경을 보장하는 자동화된 Red Hat OpenShift 인증 워크플로를 거칩니다. 인증은 차트의 무결성을 보장하고 Red Hat OpenShift 클러스터에서 Helm 차트가 원활하게 작동하는지 확인합니다.

7.1.3. 추가 리소스

7.2. Helm 설치

다음 섹션에서는 CLI를 사용하여 다양한 플랫폼에 Helm을 설치하는 방법을 설명합니다.

오른쪽 상단에 있는 ? 아이콘을 클릭하고 명령줄 툴을 선택하여 OpenShift Container Platform 웹 콘솔의 최신 바이너리 URL을 찾을 수도 있습니다.

사전 요구 사항

  • Go 버전 1.13 이상이 설치되어 있어야 합니다.

7.2.1. On Linux

  1. Helm 바이너리를 다운로드하여 경로에 추가합니다.

    • Linux (x86_64, amd64)

      # curl -L https://mirror.openshift.com/pub/openshift-v4/clients/helm/latest/helm-linux-amd64 -o /usr/local/bin/helm
    • Linux on IBM Z 및 IBM® LinuxONE (s390x)

      # curl -L https://mirror.openshift.com/pub/openshift-v4/clients/helm/latest/helm-linux-s390x -o /usr/local/bin/helm
    • Linux on IBM Power(ppc64le)

      # curl -L https://mirror.openshift.com/pub/openshift-v4/clients/helm/latest/helm-linux-ppc64le -o /usr/local/bin/helm
  2. 바이너리 파일을 실행 가능하게 합니다.

    # chmod +x /usr/local/bin/helm
  3. 설치된 버전을 확인합니다.

    $ helm version

    출력 예

    version.BuildInfo{Version:"v3.0", GitCommit:"b31719aab7963acf4887a1c1e6d5e53378e34d93", GitTreeState:"clean", GoVersion:"go1.13.4"}

7.2.2. Windows 7/8

  1. 최신 .exe 파일을 다운로드하여 기본 설정 디렉터리에 배치합니다.
  2. 시작을 마우스 오른쪽 버튼으로 클릭하고 제어판을 클릭합니다.
  3. 시스템 및 보안을 선택하고 시스템을 클릭합니다.
  4. 왼쪽 메뉴에서 고급 시스템 설정을 선택하고 아래에 있는 환경 변수를 클릭합니다.
  5. 변수 섹션에서 경로를 선택하고 편집을 클릭합니다.
  6. 새로 생성을 클릭하고 필드에 .exe 파일이 있는 폴더의 경로를 입력하거나 검색을 클릭하고 디렉터리를 선택한 후 확인을 클릭합니다.

7.2.3. Windows 10

  1. 최신 .exe 파일을 다운로드하여 기본 설정 디렉터리에 배치합니다.
  2. 검색을 클릭하고 env 또는 environment를 입력합니다.
  3. 계정의 환경 변수 편집을 선택합니다.
  4. 변수 섹션에서 경로를 선택하고 편집을 클릭합니다.
  5. 새로 생성을 클릭하고 필드에 exe 파일이 있는 디렉터리의 경로를 입력하거나 검색을 클릭하고 디렉터리를 선택한 후 확인을 클릭합니다.

7.2.4. MacOS

  1. Helm 바이너리를 다운로드하여 경로에 추가합니다.

    # curl -L https://mirror.openshift.com/pub/openshift-v4/clients/helm/latest/helm-darwin-amd64 -o /usr/local/bin/helm
  2. 바이너리 파일을 실행 가능하게 합니다.

    # chmod +x /usr/local/bin/helm
  3. 설치된 버전을 확인합니다.

    $ helm version

    출력 예

    version.BuildInfo{Version:"v3.0", GitCommit:"b31719aab7963acf4887a1c1e6d5e53378e34d93", GitTreeState:"clean", GoVersion:"go1.13.4"}

7.3. 사용자 정의 Helm 차트 리포지터리 구성

다음 방법을 사용하여 OpenShift Container Platform 클러스터에 Helm 릴리스를 생성할 수 있습니다.

  • The CLI.
  • 웹 콘솔의 개발자 화면입니다.

개발자 카탈로그는 웹 콘솔의 개발자 관점으로 클러스터에서 사용할 수 있는 Helm 차트를 표시합니다. 기본적으로 Red Hat OpenShift Helm 차트 리포지터리의 Helm 차트를 나열합니다. 차트 목록은 Red Hat Helm 인덱스 파일을 참조하십시오.

클러스터 관리자는 기본 클러스터 범위의 Helm 리포지터리와 별도로 여러 클러스터 범위 및 네임스페이스 범위의 Helm 차트 리포지터리를 추가하고 개발자 카탈로그에 이러한 리포지토리의 Helm 차트를 표시할 수 있습니다.

적절한 RBAC(역할 기반 액세스 제어) 권한이 있는 일반 사용자 또는 프로젝트 멤버로 기본 클러스터 범위의 Helm 리포지터리 외에도 여러 네임스페이스 범위의 Helm 차트 리포지터리를 추가하고 개발자 카탈로그에 해당 리포지토리의 Helm 차트를 표시할 수 있습니다.

웹 콘솔의 개발자 화면에서 Helm 페이지를 사용하여 다음을 수행할 수 있습니다.

  • 생성 버튼을 사용하여 Helm 릴리스 및 리포지토리를 생성합니다.
  • 클러스터 범위 또는 네임스페이스 범위의 Helm 차트 리포지터리를 생성, 업데이트 또는 삭제합니다.
  • Repositories 탭에서 기존 Helm 차트 리포지터리 목록을 확인합니다. 이 리포지토리는 클러스터 범위 또는 네임스페이스 범위로 쉽게 구분할 수 있습니다.

7.3.1. OpenShift Container Platform 클러스터에 Helm 차트 설치

사전 요구 사항

  • 실행 중인 OpenShift Container Platform 클러스터가 있고 로그인되어 있어야 합니다.
  • Helm이 설치되어 있어야 합니다.

절차

  1. 새 프로젝트를 생성합니다.

    $ oc new-project vault
  2. 로컬 Helm 클라이언트에 Helm 차트 리포지터리를 추가합니다.

    $ helm repo add openshift-helm-charts https://charts.openshift.io/

    출력 예

    "openshift-helm-charts" has been added to your repositories

  3. 리포지터리를 업데이트합니다.

    $ helm repo update
  4. HashiCorp Vault 예제를 설치합니다.

    $ helm install example-vault openshift-helm-charts/hashicorp-vault

    출력 예

    NAME: example-vault
    LAST DEPLOYED: Fri Mar 11 12:02:12 2022
    NAMESPACE: vault
    STATUS: deployed
    REVISION: 1
    NOTES:
    Thank you for installing HashiCorp Vault!

  5. 차트가 성공적으로 설치되었는지 확인합니다.

    $ helm list

    출력 예

    NAME         	NAMESPACE	REVISION	UPDATED                                	STATUS  	CHART       	APP VERSION
    example-vault	vault    	1       	2022-03-11 12:02:12.296226673 +0530 IST	deployed	vault-0.19.0	1.9.2

7.3.2. 개발자 화면을 사용하여 Helm 릴리스 생성

웹 콘솔의 개발자 화면 또는 CLI를 사용하여 개발자 카탈로그에 나열된 Helm 차트에서 릴리스를 선택하고 생성할 수 있습니다. Helm 차트를 설치하고 웹 콘솔의 개발자 화면에서 Helm 릴리스를 생성할 수 있습니다.

사전 요구 사항

절차

개발자 카탈로그에 제공된 Helm 차트에서 Helm 릴리스를 생성하려면 다음을 수행합니다.

  1. 개발자 화면에서 +추가 보기로 이동하여 프로젝트를 선택합니다. 그런 다음 Helm 차트 옵션을 클릭하여 개발자 카탈로그의 모든 Helm 차트를 확인합니다.
  2. 차트를 선택하고 해당 차트에 대한 설명, README 및 기타 세부 정보를 읽습니다.
  3. Create를 클릭합니다.

    그림 7.1. 개발자 카탈로그의 Helm 차트

    odc helm chart devcatalog new
  4. Helm 릴리스 생성 페이지에서 다음을 수행합니다.

    1. 릴리스 이름 필드에 고유한 릴리스 이름을 입력합니다.
    2. 차트 버전 드롭다운 목록에서 필요한 차트 버전을 선택합니다.
    3. 보기에서 또는 YAML 보기를 사용하여 Helm 차트를 구성합니다.

      참고

      가능한 경우 YAML 보기양식 보기를 전환할 수 있습니다. 다른 보기로 전환해도 데이터는 유지됩니다.

    4. 생성을 클릭하여 Helm 릴리스를 생성합니다. 웹 콘솔은 토폴로지 보기에 새 릴리스를 표시합니다.

      Helm 차트에 릴리스 노트가 있는 경우 웹 콘솔에 해당 정보가 표시됩니다.

      Helm 차트에서 워크로드를 생성하면 웹 콘솔에서 Topology 또는 Helm 릴리스 세부 정보 페이지에 표시합니다. 워크로드는 DaemonSet,CronJob,Pod,Deployment, DeploymentConfig 입니다.

    5. Helm 릴리스 페이지에서 새로 생성된 Helm 릴리스를 확인합니다.

측면 패널의 작업 버튼을 사용하거나 Helm 릴리스를 마우스 오른쪽 버튼으로 클릭하여 Helm 릴리스를 업그레이드, 롤백 또는 삭제할 수 있습니다.

7.3.3. 웹 터미널에서 Helm 사용

웹 콘솔의 개발자 화면에서 웹 터미널에 액세스하여 Helm을 사용할 수 있습니다.

7.3.4. OpenShift Container Platform에서 사용자 정의 Helm 차트 생성

절차

  1. 새 프로젝트를 생성합니다.

    $ oc new-project nodejs-ex-k
  2. OpenShift Container Platform 오브젝트가 포함된 Node.js 차트 예를 다운로드합니다.

    $ git clone https://github.com/redhat-developer/redhat-helm-charts
  3. 샘플 차트가 있는 디렉터리로 이동합니다.

    $ cd redhat-helm-charts/alpha/nodejs-ex-k/
  4. Chart.yaml 파일을 편집하고 차트에 대한 설명을 추가합니다.

    apiVersion: v2 1
    name: nodejs-ex-k 2
    description: A Helm chart for OpenShift 3
    icon: https://static.redhat.com/libs/redhat/brand-assets/latest/corp/logo.svg 4
    version: 0.2.1 5
    1
    차트 API 버전. Helm 3 이상이 필요한 Helm 차트 v2여야 합니다.
    2
    차트 이름.
    3
    차트 설명.
    4
    아이콘으로 사용할 이미지의 URL.
    5
    차트 버전(SemVer) 2.0.0 사양에 따라 차트 버전입니다.
  5. 차트 형식이 올바르게 지정되었는지 확인합니다.

    $ helm lint

    출력 예

    [INFO] Chart.yaml: icon is recommended
    
    1 chart(s) linted, 0 chart(s) failed

  6. 이전 디렉터리 수준으로 이동합니다.

    $ cd ..
  7. 차트를 설치합니다.

    $ helm install nodejs-chart nodejs-ex-k
  8. 차트가 성공적으로 설치되었는지 확인합니다.

    $ helm list

    출력 예

    NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
    nodejs-chart nodejs-ex-k 1 2019-12-05 15:06:51.379134163 -0500 EST deployed nodejs-0.1.0  1.16.0

7.3.5. 사용자 정의 Helm 차트 리포지터리 추가

클러스터 관리자는 사용자 정의 Helm 차트 리포지터리를 클러스터에 추가하여 개발자 카탈로그에서 해당 리포지터리의 Helm 차트에 대한 액세스를 활성화할 수 있습니다.

절차

  1. 새 Helm 차트 리포지터리를 추가하려면 클러스터에 Helm 차트 리포지터리 CR(사용자 정의 리소스)을 추가해야 합니다.

    샘플 Helm 차트 리포지터리 CR

    apiVersion: helm.openshift.io/v1beta1
    kind: HelmChartRepository
    metadata:
      name: <name>
    spec:
     # optional name that might be used by console
     # name: <chart-display-name>
      connectionConfig:
        url: <helm-chart-repository-url>

    예를 들어 Azure 샘플 차트 리포지터리를 추가하려면 다음을 실행합니다.

    $ cat <<EOF | oc apply -f -
    apiVersion: helm.openshift.io/v1beta1
    kind: HelmChartRepository
    metadata:
      name: azure-sample-repo
    spec:
      name: azure-sample-repo
      connectionConfig:
        url: https://raw.githubusercontent.com/Azure-Samples/helm-charts/master/docs
    EOF
  2. 웹 콘솔에서 개발자 카탈로그로 이동하여 차트 리포지터리의 Helm 차트가 표시되는지 확인합니다.

    예를 들어 차트 리포지터리 필터를 사용하여 리포지터리의 Helm 차트를 검색합니다.

    그림 7.2. 차트 리포지터리 필터

    odc helm 차트 리포지터리 필터
    참고

    클러스터 관리자가 모든 차트 리포지터리를 제거하는 경우 +추가 보기, 개발자 카탈로그 및 왼쪽 탐색 패널에서 Helm 옵션을 볼 수 없습니다.

7.3.6. 네임스페이스 범위의 사용자 정의 Helm 차트 리포지터리 추가

Helm 리포지터리의 클러스터 범위 HelmChartRepository CRD(사용자 정의 리소스 정의)는 관리자가 Helm 리포지토리를 사용자 정의 리소스로 추가할 수 있는 기능을 제공합니다. 네임스페이스 범위의 ProjectHelmChartRepository CRD를 사용하면 적절한 역할 기반 액세스 제어(RBAC) 권한이 있는 프로젝트 멤버가 선택한 Helm 리포지토리 리소스를 생성할 수 있지만 네임스페이스로 범위가 지정됩니다. 이러한 프로젝트 멤버는 클러스터 범위 및 네임스페이스 범위의 Helm 리포지터리 리소스의 차트를 볼 수 있습니다.

참고
  • 관리자는 사용자가 네임스페이스 범위의 Helm 리포지터리 리소스를 생성하지 못하도록 제한할 수 있습니다. 관리자는 사용자를 제한함으로써 클러스터 역할 대신 네임스페이스 역할을 통해 RBAC를 제어할 수 있습니다. 이를 통해 사용자에게 불필요한 권한 상승을 방지하고 권한 없는 서비스 또는 애플리케이션에 대한 액세스를 방지할 수 있습니다.
  • 네임스페이스 범위의 Helm 리포지터리를 추가하면 기존 클러스터 범위의 Helm 리포지터리의 동작에 영향을 미치지 않습니다.

적절한 RBAC 권한이 있는 일반 사용자 또는 프로젝트 멤버로 사용자 정의 네임스페이스 범위의 Helm 차트 리포지터리를 클러스터에 추가하고 개발자 카탈로그에서 해당 리포지터리의 Helm 차트에 액세스할 수 있습니다.

절차

  1. 새 네임스페이스 범위의 Helm 차트 리포지터리를 추가하려면 네임스페이스에 Helm 차트 리포지터리 CR(사용자 정의 리소스)을 추가해야 합니다.

    샘플 네임스페이스 범위 Helm 차트 리포지터리 CR

    apiVersion: helm.openshift.io/v1beta1
    kind: ProjectHelmChartRepository
    metadata:
      name: <name>
    spec:
      url: https://my.chart-repo.org/stable
    
      # optional name that might be used by console
      name: <chart-repo-display-name>
    
      # optional and only needed for UI purposes
      description: <My private chart repo>
    
      # required: chart repository URL
      connectionConfig:
        url: <helm-chart-repository-url>

    예를 들어 my-namespace 네임스페이스에 범위가 지정된 Azure 샘플 차트 리포지터리를 추가하려면 다음을 실행합니다.

    $ cat <<EOF | oc apply --namespace my-namespace -f -
    apiVersion: helm.openshift.io/v1beta1
    kind: ProjectHelmChartRepository
    metadata:
      name: azure-sample-repo
    spec:
      name: azure-sample-repo
      connectionConfig:
        url: https://raw.githubusercontent.com/Azure-Samples/helm-charts/master/docs
    EOF

    출력에서 네임스페이스 범위의 Helm 차트 리포지터리 CR이 생성되었는지 확인합니다.

    출력 예

    projecthelmchartrepository.helm.openshift.io/azure-sample-repo created

  2. 웹 콘솔에서 개발자 카탈로그 로 이동하여 차트 리포지토리의 Helm 차트가 my-namespace 네임스페이스에 표시되는지 확인합니다.

    예를 들어 차트 리포지터리 필터를 사용하여 리포지터리의 Helm 차트를 검색합니다.

    그림 7.3. 네임스페이스에서 차트 리포지터리 필터링

    odc namespace helm chart repo 필터

    또는 다음을 실행합니다.

    $ oc get projecthelmchartrepositories --namespace my-namespace

    출력 예

    NAME                     AGE
    azure-sample-repo        1m

    참고

    적절한 RBAC 권한이 있는 클러스터 관리자 또는 일반 사용자가 특정 네임스페이스의 모든 차트 리포지터리를 제거하는 경우 +Add view, Developer Catalog, 및 left navigation panel에서 Helm 옵션을 볼 수 없습니다.

7.3.7. 인증 정보 및 CA 인증서를 생성하여 Helm 차트 리포지터리 추가

일부 Helm 차트 리포지터리는 연결하려면 인증 정보 및 사용자 정의 CA(인증 기관) 인증서가 필요합니다. 웹 콘솔 및 CLI를 사용하여 인증 정보 및 인증서를 추가할 수 있습니다.

프로세스

CLI를 사용하여 인증 정보 및 인증서를 구성한 후 Helm 차트 리포지터리를 추가하려면 다음을 실행합니다.

  1. openshift-config 네임스페이스에서 PEM 인코딩 형식의 사용자 정의 CA 인증서로 ConfigMap 오브젝트를 생성한 후 구성 맵 내의 ca-bundle.crt 키에 저장합니다.

    $ oc create configmap helm-ca-cert \
    --from-file=ca-bundle.crt=/path/to/certs/ca.crt \
    -n openshift-config
  2. openshift-config 네임스페이스에서 Secret 오브젝트를 생성하여 클라이언트 TLS 구성을 추가합니다.

    $ oc create secret tls helm-tls-configs \
    --cert=/path/to/certs/client.crt \
    --key=/path/to/certs/client.key \
    -n openshift-config

    클라이언트 인증서 및 키는 PEM 인코딩 형식이어야 하며 각각 tls.crttls.key 키에 저장되어야 합니다.

  3. 다음과 같이 Helm 리포지터리를 추가합니다.

    $ cat <<EOF | oc apply -f -
    apiVersion: helm.openshift.io/v1beta1
    kind: HelmChartRepository
    metadata:
      name: <helm-repository>
    spec:
      name: <helm-repository>
      connectionConfig:
        url: <URL for the Helm repository>
        tlsConfig:
            name: helm-tls-configs
        ca:
    	name: helm-ca-cert
    EOF

    ConfigMapSecrettlsConfigca 필드를 사용하는 HelmChartRepository CR에서 사용됩니다. 이러한 인증서는 Helm 리포지터리 URL에 연결하는 데 사용됩니다.

  4. 기본적으로 모든 인증된 사용자는 모든 구성된 차트에 액세스할 수 있습니다. 하지만 인증서가 필요한 차트 리포지터리의 경우 다음과 같이 사용자에게 openshift-config 네임스페이스의 helm-ca-cert 구성 맵과 helm-tls-configs 시크릿에 대한 읽기 액세스 권한을 제공해야 합니다.

    $ cat <<EOF | kubectl apply -f -
    apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      namespace: openshift-config
      name: helm-chartrepos-tls-conf-viewer
    rules:
    - apiGroups: [""]
      resources: ["configmaps"]
      resourceNames: ["helm-ca-cert"]
      verbs: ["get"]
    - apiGroups: [""]
      resources: ["secrets"]
      resourceNames: ["helm-tls-configs"]
      verbs: ["get"]
    ---
    kind: RoleBinding
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      namespace: openshift-config
      name: helm-chartrepos-tls-conf-viewer
    subjects:
      - kind: Group
        apiGroup: rbac.authorization.k8s.io
        name: 'system:authenticated'
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: Role
      name: helm-chartrepos-tls-conf-viewer
    EOF

7.3.8. 인증 수준에 따라 Helm 차트 필터링

개발자 카탈로그의 인증 수준에 따라 Helm 차트를 필터링할 수 있습니다.

프로세스

  1. 개발자 화면에서 +추가 보기로 이동하여 프로젝트를 선택합니다.
  2. 개발자 카탈로그 타일에서 Helm 차트 옵션을 선택하여 개발자 카탈로그의 모든 Helm 차트를 확인합니다.
  3. 필요한 차트를 필터링하려면 Helm 차트 목록 왼쪽에 있는 필터를 사용합니다.

    • 차트 리포지토리 필터를 사용하여 Red Hat 인증 차트 또는 OpenShift Helm 차트에서 제공하는 차트를 필터링합니다.
    • 소스 필터를 사용하여 파트너,커뮤니티 또는 Red Hat에서 제공한 차트를 필터링합니다. 인증 차트는 ( odc verified icon ) 아이콘으로 표시됩니다.
참고

공급업체 유형이 하나뿐이면 소스 필터가 표시되지 않습니다.

이제 필요한 차트를 선택하고 설치할 수 있습니다.

7.3.9. Helm 차트 리포지터리 비활성화

HelmChartRepository 사용자 정의 리소스에서 disabled 속성을 true 로 설정하여 카탈로그의 특정 Helm 차트 리포지터리에서 Helm 차트를 비활성화할 수 있습니다.

프로세스

  • CLI를 사용하여 Helm 차트 리포지터리를 비활성화하려면 disabled: true 플래그를 사용자 정의 리소스에 추가합니다. 예를 들어 Azure 샘플 차트 리포지터리를 제거하려면 다음을 실행합니다.

    $ cat <<EOF | oc apply -f -
    apiVersion: helm.openshift.io/v1beta1
    kind: HelmChartRepository
    metadata:
      name: azure-sample-repo
    spec:
      connectionConfig:
       url:https://raw.githubusercontent.com/Azure-Samples/helm-charts/master/docs
      disabled: true
    EOF
  • 웹 콘솔을 사용하여 최근에 추가된 Helm 차트 리포지터리를 비활성화하려면 다음을 수행합니다.

    1. 사용자 정의 리소스 정의로 이동하여 HelmChartRepository 사용자 정의 리소스를 검색합니다.
    2. 인스턴스로 이동하여 비활성화할 저장소를 찾아 이름을 클릭합니다.
    3. YAML 탭으로 이동하여 spec 섹션에 disabled: true 플래그를 추가하고 저장을 클릭합니다.

      예제

      spec:
        connectionConfig:
          url: <url-of-the-repositoru-to-be-disabled>
        disabled: true

      이제 리포지터리가 비활성화되어 카탈로그에 표시되지 않습니다.

7.4. Helm 릴리스 작업

웹 콘솔의 개발자 화면을 사용하여 Helm 릴리스를 업데이트, 롤백 또는 삭제할 수 있습니다.

7.4.1. 사전 요구 사항

7.4.2. Helm 릴리스 업그레이드

Helm 릴리스를 업그레이드하여 새 차트 버전으로 업그레이드하거나 릴리스 구성을 업데이트할 수 있습니다.

프로세스

  1. 토폴로지 보기에서 Helm 릴리스를 선택하여 측면 패널을 확인합니다.
  2. 작업Helm 릴리스 업그레이드를 클릭합니다.
  3. Helm 릴리스 업그레이드 페이지에서 업그레이드할 차트 버전을 선택한 다음 업그레이드를 클릭하면 또 하나의 Helm 릴리스가 생성됩니다. Helm 릴리스 페이지에 두 가지 리버전이 표시됩니다.

7.4.3. Helm 릴리스 롤백

릴리스가 실패하면 Helm 릴리스를 이전 버전으로 롤백할 수 있습니다.

프로세스

Helm 보기를 사용하여 릴리스를 롤백하려면 다음을 수행합니다.

  1. 개발자 화면에서 Helm 보기로 이동하여 네임스페이스에서 Helm 릴리스를 확인합니다.
  2. 나열된 릴리스 옆에 있는 옵션 메뉴 kebab 를 클릭하고 롤백 을 선택합니다.
  3. 롤백 Helm 릴리스 페이지에서 롤백할 리버전을 선택하고 롤백을 클릭합니다.
  4. Helm 릴리스 페이지에서 차트를 클릭하여 해당 릴리스의 세부 정보 및 리소스를 확인합니다.
  5. 리버전 내역 탭으로 이동하여 차트의 리버전을 모두 확인합니다.

    그림 7.4. Helm 리버전 내역

    odc helm revision history
  6. 필요한 경우 특정 버전 옆에 있는 옵션 메뉴 kebab 를 추가로 사용하고 롤백할 리버전을 선택할 수 있습니다.

7.4.4. Helm 릴리스 삭제

프로세스

  1. 토폴로지 보기에서 Helm 릴리스를 마우스 오른쪽 버튼으로 클릭하고 Helm 릴리스 삭제 를 선택합니다.
  2. 확인 프롬프트에서 차트 이름을 입력하고 삭제 를 클릭합니다.

8장. 배포

8.1. Deployment 및 DeploymentConfig 오브젝트 이해

OpenShift Container Platform의 DeploymentDeploymentConfig API 오브젝트에서는 일반적인 사용자 애플리케이션을 세밀하게 관리할 수 있도록 유사하지만 서로 다른 두 가지 방법을 제공합니다. 이러한 오브젝트는 다음과 같이 별도의 API 오브젝트로 구성됩니다.

  • Deployment 또는 DeploymentConfig 오브젝트: 특정 애플리케이션 구성 요소의 원하는 상태를 Pod 템플릿으로 설명합니다.
  • 배포 오브젝트에는 특정 시점의 배포 상태 레코드가 Pod 템플릿으로 포함된 하나 이상의 복제본 세트가 포함됩니다. 마찬가지로 DeploymentConfig 오브젝트에는 복제본 세트 앞에 오는 복제 컨트롤러가 한 개 이상 포함됩니다.
  • 하나 이상의 Pod: 특정 버전의 애플리케이션 인스턴스를 나타냅니다.

DeploymentConfig 오브젝트에서 제공하는 특정 기능 또는 동작이 필요하지 않은 경우 Deployment 오브젝트를 사용합니다.

8.1.1. 배포 블록 빌드

배포 및 배포 구성은 각각 기본 Kubernetes API 오브젝트인 ReplicaSetReplicationController를 빌딩 블록으로 사용하여 활성화됩니다.

사용자는 Deployment 또는 DeploymentConfig 오브젝트가 소유한 복제본 세트, 복제 컨트롤러 또는 Pod를 조작할 필요가 없습니다. 배포 시스템을 통해 변경 사항이 적절하게 전파됩니다.

작은 정보

기존 배포 전략이 사용 사례에 적합하지 않고 배포 라이프사이클 중 수동 단계를 실행해야 하는 경우에는 사용자 정의 배포 전략을 생성해야 합니다.

다음 섹션에서는 이러한 오브젝트에 대해 자세히 설명합니다.

8.1.1.1. 복제본 세트

ReplicaSet 은 지정된 수의 Pod 복제본이 언제든지 실행되도록 하는 기본 Kubernetes API 오브젝트입니다.

참고

사용자 정의 업데이트 오케스트레이션이 필요한 경우에만 복제본 세트를 사용하거나 업데이트가 필요하지 않습니다. 그러지 않으면 배포를 사용하십시오. 복제본 세트는 독립적으로 사용할 수 있지만 배포에서 Pod 생성, 삭제, 업데이트를 오케스트레이션하는 데 사용합니다. 배포는 복제본 세트를 자동으로 관리하고 Pod에 선언적 업데이트를 제공하며 생성한 복제본 세트를 수동으로 관리할 필요가 없습니다.

다음은 ReplicaSet 정의의 예입니다.

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: frontend-1
  labels:
    tier: frontend
spec:
  replicas: 3
  selector: 1
    matchLabels: 2
      tier: frontend
    matchExpressions: 3
      - {key: tier, operator: In, values: [frontend]}
  template:
    metadata:
      labels:
        tier: frontend
    spec:
      containers:
      - image: openshift/hello-openshift
        name: helloworld
        ports:
        - containerPort: 8080
          protocol: TCP
      restartPolicy: Always
1
리소스 집합에 대한 레이블 쿼리입니다. matchLabelsmatchExpressions의 결과는 논리적으로 결합됩니다.
2
선택기와 일치하는 라벨을 사용하여 리소스를 지정하는 일치 기반 선택기입니다.
3
키를 필터링하는 세트 기반 선택기입니다. 키가 tier이고 값이 frontend인 모든 리소스를 선택합니다.
8.1.1.2. 복제 컨트롤러

복제본 세트와 유사하게 복제 컨트롤러는 항상 지정된 수의 Pod 복제본이 실행되도록 합니다. Pod가 종료되거나 삭제되면 복제 컨트롤러에서 정의된 수까지 더 많은 것을 인스턴스화합니다. 마찬가지로 필요한 것보다 많은 Pod가 실행되고 있는 경우에는 정의된 수에 맞게 필요한 개수의 Pod를 삭제합니다. 복제본 세트와 복제 컨트롤러의 차이점은 복제본 세트는 세트 기반 선택기 요구 사항을 지원하는 반면 복제 컨트롤러는 일치 기반 선택기 요구 사항만 지원한다는 점입니다.

복제 컨트롤러 구성은 다음과 같이 구성됩니다.

  • 런타임에 조정할 수 있는 원하는 복제본 수
  • 복제된 Pod를 생성할 때 사용할 Pod 정의
  • 관리형 Pod를 확인하는 선택기

선택기는 복제 컨트롤러에서 관리하는 Pod에 할당한 라벨 세트입니다. 이러한 라벨은 복제 컨트롤러에서 인스턴스화하는 Pod 정의에 포함됩니다. 복제 컨트롤러에서는 필요에 따라 조정할 수 있도록 선택기를 사용하여 이미 실행 중인 Pod의 인스턴스 수를 결정합니다.

복제 컨트롤러에서 로드나 트래픽을 추적하지 않으므로 로드 또는 트래픽을 기반으로 자동 스케일링하지 않습니다. 대신 외부 Autoscaler에서 복제본 수를 조정해야 합니다.

참고

DeploymentConfig 를 사용하여 복제 컨트롤러를 직접 생성하는 대신 복제 컨트롤러를 생성합니다.

사용자 지정 오케스트레이션이 필요하거나 업데이트가 필요하지 않은 경우 복제 컨트롤러 대신 복제본 세트를 사용합니다.

다음은 복제 컨트롤러 정의의 예입니다.

apiVersion: v1
kind: ReplicationController
metadata:
  name: frontend-1
spec:
  replicas: 1  1
  selector:    2
    name: frontend
  template:    3
    metadata:
      labels:  4
        name: frontend 5
    spec:
      containers:
      - image: openshift/hello-openshift
        name: helloworld
        ports:
        - containerPort: 8080
          protocol: TCP
      restartPolicy: Always
1
실행할 Pod의 사본 수입니다.
2
실행할 Pod의 라벨 선택기입니다.
3
컨트롤러에서 생성하는 Pod용 템플릿입니다.
4
Pod의 라벨에는 라벨 선택기의 해당 항목이 포함되어야 합니다.
5
매개변수를 확장한 후 최대 이름 길이는 63자입니다.

8.1.2. 배포

Kubernetes는 OpenShift Container Platform에서 Deployment라는 최상위 기본 API 오브젝트 유형을 제공합니다. Deployment 오브젝트는 특정 애플리케이션 구성 요소의 원하는 상태를 Pod 템플릿으로 설명합니다. 배포에서는 Pod 라이프사이클을 오케스트레이션하는 복제본 세트를 생성합니다.

예를 들어 다음 배포 정의에서는 하나의 hello-openshift Pod를 가져오는 복제본 세트를 생성합니다.

배포 정의

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-openshift
spec:
  replicas: 1
  selector:
    matchLabels:
      app: hello-openshift
  template:
    metadata:
      labels:
        app: hello-openshift
    spec:
      containers:
      - name: hello-openshift
        image: openshift/hello-openshift:latest
        ports:
        - containerPort: 80

8.1.3. DeploymentConfig 오브젝트

OpenShift Container Platform은 복제 컨트롤러를 기반으로 소프트웨어 개발 및 배포 라이프사이클에 대한 지원을 DeploymentConfig 오브젝트의 개념으로 확장합니다. 가장 간단한 경우 DeploymentConfig 오브젝트는 새 복제 컨트롤러를 생성하고 이 컨트롤러에서 Pod를 시작할 수 있도록 설정합니다.

그러나 DeploymentConfig 오브젝트의 OpenShift Container Platform 배포에서는 이미지의 기존 배포에서 새 버전으로 전환하는 기능도 제공하고 복제 컨트롤러를 생성하기 전이나 후에 실행할 후크도 정의합니다.

DeploymentConfig 배포 시스템에서는 다음 기능을 제공합니다.

  • 실행 중인 애플리케이션에 대한 템플릿인 DeploymentConfig 오브젝트
  • 이벤트에 대한 응답으로 자동 배포를 실행하는 트리거
  • 이전 버전에서 새 버전으로의 전환을 위한 사용자 정의 가능 배포 전략. 전략은 일반적으로 배포 프로세스라는 Pod 내에서 실행됩니다.
  • 배포 라이프사이클 중 다른 시점에서 사용자 정의 동작을 실행하는 일련의 후크(라이프사이클 후크)
  • 배포가 실패하는 경우 롤백을 수동 또는 자동으로 지원하기 위한 애플리케이션 버전 관리
  • 복제본 수동 스케일링 및 자동 스케일링

DeploymentConfig 오브젝트를 생성하면 DeploymentConfig 오브젝트의 Pod 템플릿을 나타내는 복제 컨트롤러가 생성됩니다. 배포가 변경되면 최신 Pod 템플릿을 사용하여 새 복제 컨트롤러가 생성되고 배포 프로세스가 실행되어 이전 복제 컨트롤러가 축소되고 새 복제 컨트롤러가 확장됩니다.

애플리케이션 인스턴스는 생성 시 서비스 로드 밸런서와 라우터 모두에서 자동으로 추가 및 제거됩니다. 애플리케이션에서 TERM 신호를 수신할 때 정상 종료를 지원하는 경우 실행 중인 사용자 연결을 정상적으로 완료할 수 있는 기회를 제공할 수 있습니다.

OpenShift Container Platform DeploymentConfig 오브젝트는 다음과 같은 세부 정보를 정의합니다.

  1. ReplicationController 정의의 요소
  2. 새 배포를 자동으로 생성하는 트리거
  3. 배포 간 전환을 위한 전략
  4. 라이프사이클 후크

배포가 수동 또는 자동으로 트리거될 때마다 배포자 Pod에서 배포를 관리합니다(이전 복제 컨트롤러 축소, 새 복제 컨트롤러 확장, 후크 실행 포함). 배포 Pod는 배포 로그를 유지하기 위해 배포 완료 후 무기한으로 유지됩니다. 배포가 다른 배포로 대체되면 필요한 경우 쉽게 롤백할 수 있도록 이전 복제 컨트롤러가 유지됩니다.

DeploymentConfig 정의의 예

apiVersion: apps.openshift.io/v1
kind: DeploymentConfig
metadata:
  name: frontend
spec:
  replicas: 5
  selector:
    name: frontend
  template: { ... }
  triggers:
  - type: ConfigChange 1
  - imageChangeParams:
      automatic: true
      containerNames:
      - helloworld
      from:
        kind: ImageStreamTag
        name: hello-openshift:latest
    type: ImageChange  2
  strategy:
    type: Rolling      3

1
구성 변경 트리거를 사용하면 배포 구성의 Pod 템플릿에서 변경이 탐지될 때마다 새 복제 컨트롤러가 생성됩니다.
2
이름이 지정된 이미지 스트림에 새 버전의 백업 이미지가 제공될 때마다 이미지 변경 트리거를 통해 새 배포가 생성됩니다.
3
기본 Rolling 전략을 사용하면 배포 사이에 다운타임 없이 전환할 수 있습니다.

8.1.4. Deployment 및 DeploymentConfig 오브젝트 비교

OpenShift Container Platform에서는 Kubernetes Deployment 오브젝트와 OpenShift Container Platform 제공 DeploymentConfig 오브젝트가 모두 지원되지만 DeploymentConfig 오브젝트에서 제공하는 특정 기능 또는 동작이 필요하지 않는 한 Deployment 오브젝트를 사용하는 것이 좋습니다.

다음 섹션은 두 오브젝트 유형의 차이점에 대해 더 자세히 설명하여 사용할 유형을 결정하는 데 도움이 됩니다.

8.1.4.1. 설계

DeploymentDeploymentConfig 오브젝트의 중요한 차이점은 각 설계에서 롤아웃 프로세스에 대해 선택한 CAP theorem의 속성입니다. DeploymentConfig 오브젝트는 일관성을 선호하는 반면 Deployments 오브젝트는 일관성보다 가용성을 우선합니다.

DeploymentConfig 오브젝트의 경우 배포자 Pod를 실행하는 노드가 종료되면 대체되지 않습니다. 이 프로세스는 노드가 다시 온라인 상태가 될 때까지 기다리거나 수동으로 삭제됩니다. 노드를 수동으로 삭제하면 해당 Pod도 삭제됩니다. 즉 kubelet에서 연결된 Pod를 삭제해야 하므로 롤아웃을 해제하기 위해 Pod를 삭제할 수 없습니다.

그러나 배포 롤아웃은 컨트롤러 관리자에서 구동됩니다. 컨트롤러 관리자는 마스터에서 고가용성 모드로 실행되고 리더 선택 알고리즘을 사용하여 일관성보다 가용성을 중시합니다. 오류가 발생하는 동안 기타 마스터가 동일한 배포에서 동시에 작업할 수 있지만 이러한 문제는 오류 발생 직후 조정됩니다.

8.1.4.2. 배포별 기능
롤오버

Deployment 오브젝트의 배포 프로세스는 모든 새 롤아웃에 대해 배포자 Pod를 사용하는 DeploymentConfig 오브젝트와 달리 컨트롤러 루프에 의해 구동됩니다. 즉 Deployment 오브젝트에는 활성 상태의 복제본 세트가 가능한 한 많이 있을 수 있습니다. 결국 배포 컨트롤러에서 이전 복제본 세트를 축소하고 최신 복제본 세트를 확장합니다.

DeploymentConfig 오브젝트는 최대 하나의 배포자 Pod를 실행할 수 있습니다. 그러지 않으면 최신 복제 컨트롤러여야 하는 항목을 확장하려고 할 때 여러 배포자가 충돌할 수 있습니다. 이로 인해 어느 시점에 두 개의 복제 컨트롤러만 활성화할 수 있습니다. 결과적으로 Deployment 오브젝트에 대한 신속한 롤아웃이 빨라집니다.

비례 스케일링

배포 컨트롤러는 Deployment 오브젝트가 소유한 신규 및 이전 복제본 세트 크기에 대한 유일한 정보 소스이므로 지속적인 롤아웃을 확장할 수 있습니다. 추가 복제본은 각 복제본 세트의 크기에 비례하여 배포됩니다.

컨트롤러에서 새 복제 컨트롤러 크기에 대한 배포자 프로세스에 문제가 있기 때문에 롤아웃이 진행 중인 경우 DeploymentConfig 오브젝트를 스케일링할 수 없습니다.

롤아웃 중 정지

배포는 언제든지 정지할 수 있습니다. 따라서 지속적인 롤아웃도 정지할 수 있습니다. 그러나 현재 배포자 Pod는 일시 중지할 수 없습니다. 롤아웃 중 배포를 일시 중지하려고 하면 배포자 프로세스는 영향을 받지 않고 완료될 때까지 계속됩니다.

8.1.4.3. DeploymentConfig 오브젝트별 기능
자동 롤백

현재 배포에서는 배포에 실패하는 경우 성공적으로 배포된 마지막 복제본 세트로 자동 롤백되지 않습니다.

Trigger

배포의 Pod 템플릿이 변경될 때마다 새 롤아웃이 자동으로 트리거된다는 점에서 배포에는 암시적 구성 변경 트리거가 포함되어 있습니다. Pod 템플릿 변경 시 새 롤아웃을 수행하지 않으려면 배포를 정지하십시오.

$ oc rollout pause deployments/<name>
라이프사이클 후크

배포에서는 아직 라이프사이클 후크를 지원하지 않습니다.

사용자 정의 전략

배포에서는 사용자가 지정한 사용자 정의 배포 전략을 지원하지 않습니다.

8.2. 배포 프로세스 관리

8.2.1. DeploymentConfig 오브젝트 관리

DeploymentConfig 오브젝트는 OpenShift Container Platform 웹 콘솔의 워크로드 페이지 또는 oc CLI에서 관리할 수 있습니다. 다음 절차에서는 달리 명시하지 않는 한 CLI 사용법을 보여줍니다.

8.2.1.1. 배포 시작

롤아웃을 시작하여 애플리케이션 배포 프로세스를 시작할 수 있습니다.

프로세스

  1. 기존 DeploymentConfig 오브젝트에서 새 배포 프로세스를 시작하려면 다음 명령을 실행합니다.

    $ oc rollout latest dc/<name>
    참고

    배포 프로세스가 이미 진행 중인 경우 명령에서 메세지를 표시하고 새 복제 컨트롤러가 배포되지 않습니다.

8.2.1.2. 배포 보기

배포를 보고 애플리케이션의 모든 사용 가능한 리버전에 대한 기본 정보를 얻을 수 있습니다.

프로세스

  1. 현재 실행 중인 배포 프로세스를 포함하여 제공된 DeploymentConfig 오브젝트에 대해 최근 생성된 모든 복제 컨트롤러에 대한 세부 정보를 보려면 다음 명령을 실행합니다.

    $ oc rollout history dc/<name>
  2. 버전과 관련된 세부 정보를 보려면 --revision 플래그를 추가합니다.

    $ oc rollout history dc/<name> --revision=1
  3. DeploymentConfig 오브젝트 및 이 오브젝트의 최신 버전에 대한 자세한 내용을 보려면 oc describe 명령을 사용합니다.

    $ oc describe dc <name>
8.2.1.3. 배포 재시도

DeploymentConfig 오브젝트의 현재 리버전을 배포하지 못한 경우 배포 프로세스를 재시작할 수 있습니다.

프로세스

  1. 실패한 배포 프로세스를 재시작하려면 다음을 수행합니다.

    $ oc rollout retry dc/<name>

    최신 버전이 성공적으로 배포된 경우 명령에서 메시지를 표시하고 배포 프로세스가 다시 수행되지 않습니다.

    참고

    배포를 다시 시도하면 배포 프로세스가 다시 시작되고 새 배포 리버전이 생성되지 않습니다. 재시작한 복제 컨트롤러의 구성은 실패한 경우의 구성과 동일합니다.

8.2.1.4. 배포 롤백

롤백은 애플리케이션을 이전 리버전으로 되돌리고 REST API, CLI 또는 웹 콘솔을 사용하여 수행할 수 있습니다.

프로세스

  1. 마지막으로 성공적으로 배포된 구성 리버전으로 롤백하려면 다음을 수행합니다.

    $ oc rollout undo dc/<name>

    DeploymentConfig 오브젝트의 템플릿이 undo 명령에 지정된 배포 리버전과 일치하도록 되돌아가고 새 복제 컨트롤러가 시작됩니다. 리버전이 --to-revision을 사용하여 지정되지 않은 경우 마지막으로 성공적으로 배포된 리버전이 사용됩니다.

  2. 롤백이 완료되면 실수로 새 배포 프로세스가 시작되지 않도록 DeploymentConfig 오브젝트에서 이미지 변경 트리거가 비활성화됩니다.

    이미지 변경 트리거를 다시 활성화하려면 다음을 수행합니다.

    $ oc set triggers dc/<name> --auto
참고

배포 구성에서는 최신 배포 프로세스가 실패하는 경우 마지막으로 성공한 구성 리버전으로의 자동 롤백도 지원합니다. 이 경우 배포되지 않은 최신 템플릿은 시스템에서 그대로 유지되며 사용자가 해당 구성을 수정할 수 있습니다.

8.2.1.5. 컨테이너 내에서 명령 실행

이미지의 ENTRYPOINT 를 재정의하여 컨테이너의 시작 동작을 수정하는 명령을 컨테이너에 추가할 수 있습니다. 이 명령은 지정된 시점에 배포당 한 번만 실행할 수 있는 라이프사이클 후크와는 다릅니다.

프로세스

  1. DeploymentConfig 오브젝트의 spec 필드에 command 매개변수를 추가합니다. 또한 command(command가 존재하지 않는 경우 ENTRYPOINT)를 수정하는 args 필드를 추가할 수 있습니다.

    kind: DeploymentConfig
    apiVersion: apps.openshift.io/v1
    metadata:
      name: example-dc
    # ...
    spec:
      template:
    # ...
        spec:
         containers:
         - name: <container_name>
           image: 'image'
           command:
             - '<command>'
           args:
             - '<argument_1>'
             - '<argument_2>'
             - '<argument_3>'

    예를 들어 -jar/opt/app-root/springboots2idemo.jar 인수를 사용하여 java 명령을 실행하려면 다음을 수행합니다.

    kind: DeploymentConfig
    apiVersion: apps.openshift.io/v1
    metadata:
      name: example-dc
    # ...
    spec:
      template:
    # ...
        spec:
          containers:
            - name: example-spring-boot
              image: 'image'
              command:
                - java
              args:
                - '-jar'
                - /opt/app-root/springboots2idemo.jar
    # ...
8.2.1.6. 배포 로그 보기

프로세스

  1. 지정된 DeploymentConfig 오브젝트의 최신 리버전 로그를 스트리밍하려면 다음을 수행합니다.

    $ oc logs -f dc/<name>

    최신 리버전이 실행 중이거나 실패한 경우 명령에서 Pod 배포를 담당하는 프로세스의 로그를 반환합니다. 성공하는 경우 애플리케이션 Pod의 로그를 반환합니다.

  2. 또한 실패한 이전 배포 프로세스(복제 컨트롤러 및 배포 Pod)가 존재하고 이를 수동으로 정리하거나 삭제하지 않은 경우에만 이러한 프로세스의 로그를 볼 수 있습니다.

    $ oc logs --version=1 dc/<name>
8.2.1.7. 배포 트리거

DeploymentConfig 오브젝트에는 클러스터 내부 이벤트에 대한 응답으로 새 배포 프로세스 생성을 유도하는 트리거가 포함될 수 있습니다.

주의

DeploymentConfig 오브젝트에 트리거가 정의되어 있지 않은 경우 기본적으로 구성 변경 트리거가 추가됩니다. Trigger가 빈 필드로 정의되면 배포를 수동으로 시작해야 합니다.

구성 변경 배포 트리거

구성 변경 트리거를 사용하면 DeploymentConfig 오브젝트의 Pod 템플릿에서 구성 변경이 탐지될 때마다 새 복제 컨트롤러가 생성됩니다.

참고

DeploymentConfig 오브젝트에 구성 변경 트리거를 정의하면 DeploymentConfig 오브젝트 자체를 생성한 직후 첫 번째 복제 컨트롤러가 자동으로 생성되고 정지되지 않습니다.

구성 변경 배포 트리거

kind: DeploymentConfig
apiVersion: apps.openshift.io/v1
metadata:
  name: example-dc
# ...
spec:
# ...
  triggers:
    - type: "ConfigChange"

이미지 변경 배포 트리거

이미지 변경 트리거를 사용하면 이미지 스트림 태그 내용이 변경될 때마다(새 버전의 이미지를 내보낼 때) 새 복제 컨트롤러가 생성됩니다.

이미지 변경 배포 트리거

kind: DeploymentConfig
apiVersion: apps.openshift.io/v1
metadata:
  name: example-dc
# ...
spec:
# ...
  triggers:
    - type: "ImageChange"
      imageChangeParams:
        automatic: true 1
        from:
          kind: "ImageStreamTag"
          name: "origin-ruby-sample:latest"
          namespace: "myproject"
        containerNames:
          - "helloworld"

1
imageChangeParams.automatic 필드를 false로 설정하면 트리거가 비활성화됩니다.

위 예제에서 origin-ruby-sample 이미지 스트림의 latest 태그 값이 변경되고 새 이미지 값이 DeploymentConfig 오브젝트의 helloworld 컨테이너에 지정된 현재 이미지와 다른 경우 helloworld 컨테이너의 새 이미지를 사용하여 새 복제 컨트롤러가 생성됩니다.

참고

DeploymentConfig 오브젝트에 이미지 변경 트리거가 정의되고(구성 변경 트리거와 automatic=false 또는 automatic=true 사용) 이미지 변경 트리거가 가리키는 이미지 스트림 태그가 아직 존재하지 않는 경우 빌드에서 이미지를 가져오거나 이미지 스트림 태그로 내보내는 즉시 초기 배포 프로세스가 자동으로 시작됩니다.

8.2.1.7.1. 배포 트리거 설정

프로세스

  1. oc set triggers 명령을 사용하여 DeploymentConfig 오브젝트에 대한 배포 트리거를 설정할 수 있습니다. 예를 들어 이미지 변경 트리거를 설정하려면 다음 명령을 사용하십시오.

    $ oc set triggers dc/<dc_name> \
        --from-image=<project>/<image>:<tag> -c <container_name>
8.2.1.8. 배포 리소스 설정

배포는 노드에서 리소스(메모리, CPU, 임시 스토리지)를 사용하는 Pod에 의해 완료됩니다. 기본적으로 Pod는 바인딩되지 않은 노드 리소스를 사용합니다. 그러나 프로젝트에서 기본 컨테이너 제한을 지정하는 경우 Pod는 해당 제한까지 리소스를 사용합니다.

참고

배포를 위한 최소 메모리 제한은 12MB입니다. 메모리를 할당할 수 없음 Pod 이벤트로 인해 컨테이너가 시작되지 않으면 메모리 제한이 너무 낮은 것입니다. 메모리 제한을 늘리거나 제거합니다. 제한을 제거하면 Pod에서 바인딩되지 않은 노드 리소스를 사용할 수 있습니다.

리소스 제한을 배포 전략의 일부로 지정하여 리소스 사용을 제한할 수도 있습니다. 배포 리소스는 재현, 롤링 또는 사용자 정의 배포 전략과 함께 사용할 수 있습니다.

프로세스

  1. 다음 예에서 각 resources, cpu, memory, ephemeral-storage는 선택 사항입니다.

    kind: Deployment
    apiVersion: apps/v1
    metadata:
      name: hello-openshift
    # ...
    spec:
    # ...
      type: "Recreate"
      resources:
        limits:
          cpu: "100m" 1
          memory: "256Mi" 2
          ephemeral-storage: "1Gi" 3
    1
    cpu는 CPU 단위입니다. 100m은 0.1 CPU 단위(100 * 1e-3)를 나타냅니다.
    2
    memory는 바이트 단위입니다. 256Mi는 268435456바이트(256 * 2 ^ 20)를 나타냅니다.
    3
    ephemeral-storage는 바이트 단위입니다. 1Gi는 1073741824바이트(2 ^ 30)를 나타냅니다.

    그러나 프로젝트에 할당량을 정의한 경우 다음 두 항목 중 하나가 필요합니다.

    • requests가 명시적으로 설정된 resources 섹션:

      kind: Deployment
      apiVersion: apps/v1
      metadata:
        name: hello-openshift
      # ...
      spec:
      # ...
        type: "Recreate"
        resources:
          requests: 1
            cpu: "100m"
            memory: "256Mi"
            ephemeral-storage: "1Gi"
      1
      requests 오브젝트에 할당량의 리소스 목록에 해당하는 리소스 목록이 포함되어 있습니다.
    • 프로젝트에 정의된 제한 범위: LimitRange 오브젝트의 기본값은 배포 프로세스 중 생성된 Pod에 적용됩니다.

    배포 리소스를 설정하려면 위 옵션 중 하나를 선택하십시오. 그러지 않으면 할당량을 충족하지 못하여 배포 Pod가 생성되지 않습니다.

추가 리소스

8.2.1.9. 수동 스케일링

롤백 외에도 수동으로 스케일링하여 복제본 수를 세부적으로 제어할 수 있습니다.

참고

autoscale 명령을 사용하여 Pod를 자동 스케일링할 수도 있습니다.

프로세스

  1. DeploymentConfig 오브젝트를 수동으로 스케일링하려면 oc scale 명령을 사용합니다. 예를 들어 다음 명령은 frontend DeploymentConfig 오브젝트의 복제본 수를 3으로 설정합니다.

    $ oc scale dc frontend --replicas=3

    결국 복제본 수는 DeploymentConfig 오브젝트의 frontend에서 구성한 배포의 원하는 현재 상태로 전달됩니다.

8.2.1.10. DeploymentConfig 오브젝트에서 프라이빗 리포지토리에 액세스

프라이빗 리포지토리에서 이미지에 액세스할 수 있도록 DeploymentConfig 오브젝트에 시크릿을 추가할 수 있습니다. 이 절차에서는 OpenShift Container Platform 웹 콘솔 방법을 보여줍니다.

프로세스

  1. 새 프로젝트를 생성합니다.
  2. 워크로드시크릿으로 이동합니다.
  3. 개인 이미지 리포지토리에 액세스하기 위한 인증 정보가 포함된 시크릿을 생성합니다.
  4. 워크로드 → DeploymentConfig로 이동합니다.
  5. DeploymentConfig 오브젝트를 생성합니다.
  6. DeploymentConfig 오브젝트 편집기 페이지에서 시크릿 가져오기를 설정하고 변경 사항을 저장합니다.
8.2.1.11. 특정 노드에 Pod 할당

라벨이 지정된 노드와 함께 노드 선택기를 사용하여 Pod 배치를 제어할 수 있습니다.

클러스터 관리자는 Pod 배치를 특정 노드로 제한하기 위해 프로젝트의 기본 노드 선택기를 설정할 수 있습니다. 개발자는 Pod 구성에 노드 선택기를 설정하여 노드를 추가로 제한할 수 있습니다.

프로세스

  1. Pod를 생성할 때 노드 선택기를 추가하려면 Pod 구성을 편집하고 nodeSelector 값을 추가합니다. 이 값은 단일 Pod 구성 또는 Pod 템플릿에 추가할 수 있습니다.

    apiVersion: v1
    kind: Pod
    metadata:
      name: my-pod
    # ...
    spec:
      nodeSelector:
        disktype: ssd
    # ...

    노드 선택기가 제 위치에 있으면 생성된 Pod가 라벨이 지정된 노드에 할당됩니다. 여기 지정된 라벨은 클러스터 관리자가 추가한 라벨과 함께 사용됩니다.

    예를 들어 클러스터 관리자가 프로젝트에 type=user-noderegion=east 라벨을 추가하고 위의 disktype: ssd 라벨을 Pod에 추가하는 경우 Pod는 세 라벨이 모두 있는 노드에서만 예약됩니다.

    참고

    라벨은 하나의 값으로만 설정할 수 있으므로 관리자가 설정한 기본값이 region=eastPod 구성에 region=west인 노드 선택기를 설정하면 예약되지 않는 Pod가 생성됩니다.

8.2.1.12. 다른 서비스 계정으로 Pod 실행

기본 계정 이외의 서비스 계정으로 Pod를 실행할 수 있습니다.

프로세스

  1. DeploymentConfig 오브젝트를 편집합니다.

    $ oc edit dc/<deployment_config>
  2. serviceAccountserviceAccountName 매개변수를 spec 필드에 추가하고 사용할 서비스 계정을 지정합니다.

    apiVersion: apps.openshift.io/v1
    kind: DeploymentConfig
    metadata:
      name: example-dc
    # ...
    spec:
    # ...
      securityContext: {}
      serviceAccount: <service_account>
      serviceAccountName: <service_account>

8.3. 배포 전략 사용

배포 전략은 다운타임 없이 애플리케이션을 변경하거나 업그레이드하여 사용자가 변경 사항을 거의 알 수 있도록 합니다.

사용자는 일반적으로 라우터에서 처리하는 경로를 통해 애플리케이션에 액세스하므로 배포 전략에서는 DeploymentConfig 오브젝트 기능 또는 라우팅 기능에 중점을 둘 수 있습니다. DeploymentConfig 오브젝트 기능에 중점을 둔 전략은 애플리케이션을 사용하는 모든 경로에 영향을 미칩니다. 라우터 기능을 사용하는 전략은 개별 경로를 대상으로 합니다.

대부분의 배포 전략은 DeploymentConfig 오브젝트를 통해 지원되며 일부 추가 전략은 라우터 기능을 통해 지원됩니다.

8.3.1. 배포 전략 선택

배포 전략을 선택할 때는 다음을 고려하십시오.

  • 장기 실행 연결은 정상적으로 처리해야 합니다.
  • 데이터베이스 변환은 복잡할 수 있으며 애플리케이션과 함께 수행하고 롤백해야 합니다.
  • 애플리케이션이 마이크로 서비스와 기존 구성 요소의 하이브리드인 경우 전환을 완료하기 위해 다운타임이 필요할 수 있습니다.
  • 이 작업을 수행하려면 인프라가 있어야 합니다.
  • 격리되지 않은 테스트 환경이 있는 경우 새 버전과 이전 버전을 모두 중단할 수 있습니다.

배포 전략에서는 준비 상태 점검을 통해 새 Pod를 사용할 준비가 되었는지 확인합니다. 준비 상태 점검이 실패하면 DeploymentConfig 오브젝트에서 타임아웃될 때까지 Pod를 다시 실행하려고 합니다. 기본 타임아웃은 dc.spec.strategy.*paramsTimeoutSeconds에 설정된 값인 10m입니다.

8.3.2. 롤링 전략

롤링 배포를 통해 이전 버전의 애플리케이션 인스턴스를 새 버전의 애플리케이션 인스턴스로 대체합니다. 롤링 전략은 DeploymentConfig 오브젝트에 전략이 지정되지 않은 경우 사용되는 기본 배포 전략입니다.

롤링 배포는 일반적으로 새 Pod가 준비 상태 점검을 통해 준비 상태가 될 때까지 기다린 후 이전 구성 요소를 축소합니다. 심각한 문제가 발생하는 경우 롤링 배포가 중단될 수 있습니다.

롤링 배포를 사용하는 경우는 다음과 같습니다.

  • 애플리케이션을 업데이트하는 동안 다운타임이 발생하지 않도록 하려는 경우
  • 애플리케이션에서 이전 코드 및 새 코드가 동시에 실행되도록 지원하는 경우

롤링 배포에서는 코드의 이전 버전과 새 버전이 동시에 실행됩니다. 이를 위해서는 일반적으로 애플리케이션에서 N-1 호환성을 처리해야 합니다.

롤링 전략 정의의 예

kind: DeploymentConfig
apiVersion: apps.openshift.io/v1
metadata:
  name: example-dc
# ...
spec:
# ...
  strategy:
    type: Rolling
    rollingParams:
      updatePeriodSeconds: 1 1
      intervalSeconds: 1 2
      timeoutSeconds: 120 3
      maxSurge: "20%" 4
      maxUnavailable: "10%" 5
      pre: {} 6
     post: {}

1
개별 Pod 업데이트 사이에 대기하는 시간입니다. 이 값을 지정하지 않는 경우 기본값은 1입니다.
2
업데이트 후 배포 상태를 폴링할 때까지 대기하는 시간입니다. 이 값을 지정하지 않는 경우 기본값은 1입니다.
3
스케일링 이벤트를 중지하기 전에 대기하는 시간입니다. 선택 사항이며 기본값은 600입니다. 여기서 중지하는 경우 이전에 완료된 배포로 자동으로 롤백합니다.
4
maxSurge는 선택 사항이며 지정하지 않는 경우 기본값은 25%입니다. 다음 절차 아래의 정보를 참조하십시오.
5
maxUnavailable은 선택 사항이며 지정하지 않는 경우 기본값은 25%입니다. 다음 절차 아래의 정보를 참조하십시오.
6
prepost는 둘 다 라이프사이클 후크입니다.

롤링 전략:

  1. pre 라이프사이클 후크를 실행합니다.
  2. 서지 수에 따라 새 복제 컨트롤러를 확장합니다.
  3. 사용할 수 없는 최대 수에 따라 이전 복제 컨트롤러를 축소합니다.
  4. 새 복제 컨트롤러가 원하는 복제본 수에 도달하고 이전 복제 컨트롤러가 0으로 스케일링될 때까지 이 스케일링을 반복합니다.
  5. post 라이프사이클 후크를 실행합니다.
중요

축소할 때는 롤링 전략이 Pod가 준비될 때까지 기다립니다. 따라서 추가 스케일링이 가용성에 영향을 미치는지 확인할 수 있습니다. 확장된 Pod가 준비되지 않으면 배포 프로세스가 결국 타임아웃되어 배포에 실패합니다.

maxUnavailable 매개변수는 업데이트 중 사용할 수 없는 최대 Pod 수입니다. maxSurge 매개변수는 원래 Pod 수 이상으로 예약할 수 있는 최대 Pod 수입니다. 두 매개변수 모두 백분율 (예: 10%) 또는 절대 값(예: 2)으로 설정할 수 있습니다. 기본값은 둘 다 25%입니다.

이러한 매개변수를 사용하면 가용성 및 속도를 위해 배포를 조정할 수 있습니다. 예를 들면 다음과 같습니다.

  • maxUnavailable*=0maxSurge*=20%를 사용하면 업데이트 및 빠른 확장 중 전체 용량을 유지 관리할 수 있습니다.
  • maxUnavailable*=10%maxSurge*=0은 추가 용량을 사용하지 않고 업데이트를 수행합니다(내부 업데이트).
  • maxUnavailable*=10%maxSurge*=10%는 빠르게 확장 및 축소하고 약간의 용량 손실 가능성이 있습니다.

일반적으로 빠른 롤아웃을 원한다면 maxSurge를 사용합니다. 리소스 할당량을 고려해야 하고 부분적인 비가용성을 허용할 수 있는 경우에는 maxUnavailable을 사용합니다.

주의

maxUnavailable 의 기본 설정은 OpenShift Container Platform의 모든 머신 구성 풀에 대해 1 입니다. 이 값을 변경하지 않고 한 번에 하나의 컨트롤 플레인 노드를 업데이트하는 것이 좋습니다. 컨트롤 플레인 풀의 경우 이 값을 3 으로 변경하지 마십시오.

8.3.2.1. 카나리아 배포

OpenShift Container Platform의 모든 롤링 배포는 카나리아 배포입니다. 이전 인스턴스를 모두 교체하기 전에 새 버전(카나리아)을 테스트합니다. 준비 상태 점검이 실패하면 카나리아 인스턴스가 제거되고 DeploymentConfig 오브젝트가 자동으로 롤백됩니다.

준비 상태 점검은 애플리케이션 코드의 일부이며 새 인스턴스를 사용할 준비가 되었는지 확인하는 데 필요할 정도로 정교할 수 있습니다. 더 복잡한 애플리케이션 점검을 구현해야 하는 경우(예: 실제 사용자 워크로드를 새 인스턴스로 전송) 사용자 정의 배포를 구현하거나 Blue-Green 배포 전략을 사용하는 것이 좋습니다.

8.3.2.2. 롤링 배포 생성

롤링 배포는 OpenShift Container Platform의 기본 유형입니다. CLI를 사용하여 롤링 배포를 생성할 수 있습니다.

프로세스

  1. Quay.io 에 있는 배포 이미지 예제를 기반으로 애플리케이션을 생성합니다.

    $ oc new-app quay.io/openshifttest/deployment-example:latest
    참고

    이 이미지는 포트를 노출하지 않습니다. 애플리케이션을 외부 LoadBalancer 서비스를 통해 노출하거나 공용 인터넷을 통해 애플리케이션에 대한 액세스를 활성화하려면 이 절차를 완료한 후 oc expose dc/deployment-example --port=<port > 명령을 사용하여 서비스를 생성합니다.

  2. 라우터가 설치된 경우 경로를 통해 애플리케이션을 제공하거나 서비스 IP를 직접 사용합니다.

    $ oc expose svc/deployment-example
  3. deployment-example.<project>.<router_domain>에서 애플리케이션을 검색하여 v1 이미지가 표시되는지 확인합니다.
  4. DeploymentConfig 오브젝트를 세 개의 복제본으로 확장합니다.

    $ oc scale dc/deployment-example --replicas=3
  5. 예제의 새 버전에 latest 태그를 지정하여 새 배포를 자동으로 트리거합니다.

    $ oc tag deployment-example:v2 deployment-example:latest
  6. 브라우저에서 v2 이미지가 표시될 때까지 페이지를 새로 고칩니다.
  7. CLI를 사용하는 경우 다음 명령은 버전 1의 Pod 수와 버전 2의 Pod 수를 보여줍니다. 웹 콘솔에서 Pod가 점차 v2에 추가되고 v1에서 제거됩니다.

    $ oc describe dc deployment-example

배포 프로세스 중 새 복제 컨트롤러가 점점 확장됩니다. 새 Pod가 (준비 상태 점검을 통과하여) ready 상태로 표시되면 배포 프로세스가 계속됩니다.

Pod가 준비 상태가 되지 않으면 프로세스가 중단되고 배포가 이전 버전으로 롤백됩니다.

8.3.2.3. 개발자 화면을 사용하여 배포 편집

개발자 화면을 사용하여 배포 전략, 이미지 설정, 환경 변수 및 배포에 대한 고급 옵션을 편집할 수 있습니다.

사전 요구 사항

  • 웹 콘솔의 개발자 화면에 있습니다.
  • 애플리케이션을 생성했습니다.

프로세스

  1. 토폴로지 보기로 이동합니다.
  2. 애플리케이션을 클릭하여 세부 정보 패널을 확인합니다.
  3. 작업 드롭다운 메뉴에서 배포 편집을 선택하여 배포 편집 페이지를 확인합니다.
  4. 배포에 대한 다음 고급 옵션을 편집할 수 있습니다.

    1. 선택 사항: 롤아웃 일시 중지를 클릭한 다음 이 배포에 대한 Pause 롤아웃 을 선택하여 롤아웃을 일시 중지할 수 있습니다.

      롤아웃을 일시 중지하면 롤아웃을 트리거하지 않고 애플리케이션을 변경할 수 있습니다. 언제든지 롤아웃을 재개할 수 있습니다.

    2. 선택 사항: Replicas 수를 수정하여 이미지 인스턴스 수를 변경하려면 스케일링을 클릭합니다.
  5. 저장을 클릭합니다.
8.3.2.4. 개발자 화면을 사용하여 롤링 배포 시작

롤링 배포를 시작하여 애플리케이션을 업그레이드할 수 있습니다.

사전 요구 사항

  • 웹 콘솔의 개발자 화면에 있습니다.
  • 애플리케이션을 생성했습니다.

프로세스

  1. 토폴로지 보기에서 애플리케이션 노드를 클릭하여 측면 패널의 개요 탭을 확인합니다. 업데이트 전략은 기본값인 롤링 전략으로 설정되어 있습니다.
  2. 작업 드롭다운 메뉴에서 롤아웃 시작을 선택하여 롤링 업데이트를 시작합니다. 롤링 배포에서는 새 버전의 애플리케이션을 실행한 다음 이전 버전을 종료합니다.

    그림 8.1. 롤링 업데이트

    odc rolling update

8.3.3. 재현 전략

재현 전략에는 기본 롤아웃 동작이 있고 배포 프로세스에 코드를 삽입하는 라이프사이클 후크를 지원합니다.

재현 전략 정의의 예

kind: Deployment
apiVersion: apps/v1
metadata:
  name: hello-openshift
# ...
spec:
# ...
  strategy:
    type: Recreate
    recreateParams: 1
      pre: {} 2
      mid: {}
      post: {}

1
recreateParams는 선택 사항입니다.
2
pre, mid, post는 라이프사이클 후크입니다.

재현 전략은 다음과 같습니다.

  1. pre 라이프사이클 후크를 실행합니다.
  2. 이전 배포를 0으로 축소합니다.
  3. mid 라이프사이클 후크를 실행합니다.
  4. 새 배포를 확장합니다.
  5. post 라이프사이클 후크를 실행합니다.
중요

확장하는 동안 배포의 복제본 수가 두 개 이상인 경우 배포를 완전히 확장하기 전에 첫 번째 배포 복제본의 준비 상태를 검증합니다. 첫 번째 복제본의 검증이 실패하면 배포가 실패로 간주됩니다.

재현 배포를 사용하는 경우는 다음과 같습니다.

  • 새 코드가 시작되려면 마이그레이션 또는 기타 데이터 변환 작업을 실행해야 하는 경우
  • 새 버전과 이전 버전의 애플리케이션 코드가 동시에 실행되는 것을 지원하지 않는 경우
  • 여러 복제본에서 공유할 수 없는 RWO 볼륨을 사용하려는 경우

재현 배포에서는 잠시 동안 애플리케이션 인스턴스가 실행되지 않기 때문에 다운타임이 발생합니다. 그러나 기존 코드와 새 코드가 동시에 실행되지 않습니다.

8.3.3.1. 개발자 화면을 사용하여 배포 편집

개발자 화면을 사용하여 배포 전략, 이미지 설정, 환경 변수 및 배포에 대한 고급 옵션을 편집할 수 있습니다.

사전 요구 사항

  • 웹 콘솔의 개발자 화면에 있습니다.
  • 애플리케이션을 생성했습니다.

프로세스

  1. 토폴로지 보기로 이동합니다.
  2. 애플리케이션을 클릭하여 세부 정보 패널을 확인합니다.
  3. 작업 드롭다운 메뉴에서 배포 편집을 선택하여 배포 편집 페이지를 확인합니다.
  4. 배포에 대한 다음 고급 옵션을 편집할 수 있습니다.

    1. 선택 사항: 롤아웃 일시 중지를 클릭한 다음 이 배포에 대한 Pause 롤아웃 을 선택하여 롤아웃을 일시 중지할 수 있습니다.

      롤아웃을 일시 중지하면 롤아웃을 트리거하지 않고 애플리케이션을 변경할 수 있습니다. 언제든지 롤아웃을 재개할 수 있습니다.

    2. 선택 사항: Replicas 수를 수정하여 이미지 인스턴스 수를 변경하려면 스케일링을 클릭합니다.
  5. 저장을 클릭합니다.
8.3.3.2. 개발자 화면을 사용하여 재현 배포 시작

웹 콘솔의 개발자 화면을 사용하여 배포 전략을 기본 롤링 업데이트에서 재현 업데이트로 전환할 수 있습니다.

사전 요구 사항

  • 웹 콘솔의 개발자 화면에 있는지 확인합니다.
  • 추가 보기를 사용하여 애플리케이션을 생성하고 토폴로지 보기에 배포되었는지 확인합니다.

프로세스

재현 업데이트 전략으로 전환하고 애플리케이션을 업그레이드하려면 다음을 수행합니다.

  1. 애플리케이션을 클릭하여 세부 정보 패널을 확인합니다.
  2. 작업 드롭다운 메뉴에서 배포 구성 편집을 선택하여 애플리케이션의 배포 구성 세부 정보를 확인합니다.
  3. YAML 편집기에서 spec.strategy.typeRecreate로 변경하고 저장을 클릭합니다.
  4. 토폴로지 보기에서 노드를 선택하여 측면 패널의 개요 탭을 확인합니다. 이제 업데이트 전략재현으로 설정되어 있습니다.
  5. 작업 드롭다운 메뉴에서 롤아웃 시작을 선택하면 재현 전략을 사용하여 업데이트가 시작됩니다. 재현 전략에서는 먼저 이전 버전 애플리케이션에 대한 Pod를 종료한 다음 새 버전에 대한 Pod를 구동합니다.

    그림 8.2. 재현 업데이트

    odc recreate update

8.3.4. 사용자 정의 전략

사용자 정의 전략을 사용하면 고유의 배포 동작을 제공할 수 있습니다.

사용자 정의 전략 정의의 예

kind: DeploymentConfig
apiVersion: apps.openshift.io/v1
metadata:
  name: example-dc
# ...
spec:
# ...
  strategy:
    type: Custom
    customParams:
      image: organization/strategy
      command: [ "command", "arg1" ]
      environment:
        - name: ENV_1
          value: VALUE_1

위 예에서 organization/strategy 컨테이너 이미지는 배포 동작을 제공합니다. 선택 사항인 command 배열은 이미지의 Dockerfile에 지정된 모든 CMD 지시문을 재정의합니다. 제공되는 선택적 환경 변수는 전략 프로세스의 실행 환경에 추가됩니다.

또한 OpenShift Container Platform에서는 배포 프로세스에 다음 환경 변수를 제공합니다.

환경 변수설명

OPENSHIFT_DEPLOYMENT_NAME

복제 컨트롤러의 새 배포 이름입니다.

OPENSHIFT_DEPLOYMENT_NAMESPACE

새 배포의 이름 공간입니다.

처음에는 새 배포의 복제본 수가 0입니다. 이 전략은 사용자의 요구에 가장 적합한 논리를 사용하여 새 배포를 활성화하는 작업을 담당합니다.

또는 customParams 오브젝트를 사용하여 기존 배포 전략에 사용자 정의 배포 논리를 삽입합니다. 사용자 정의 쉘 스크립트 논리를 제공하고 openshift-deploy 바이너리를 호출합니다. 사용자는 사용자 정의 배포 컨테이너 이미지를 제공할 필요가 없습니다. 이 경우 기본 OpenShift Container Platform 배포자 이미지가 대신 사용됩니다.

kind: DeploymentConfig
apiVersion: apps.openshift.io/v1
metadata:
  name: example-dc
# ...
spec:
# ...
  strategy:
    type: Rolling
    customParams:
      command:
      - /bin/sh
      - -c
      - |
        set -e
        openshift-deploy --until=50%
        echo Halfway there
        openshift-deploy
        echo Complete

그러면 다음 배포가 생성됩니다.

Started deployment #2
--> Scaling up custom-deployment-2 from 0 to 2, scaling down custom-deployment-1 from 2 to 0 (keep 2 pods available, don't exceed 3 pods)
    Scaling custom-deployment-2 up to 1
--> Reached 50% (currently 50%)
Halfway there
--> Scaling up custom-deployment-2 from 1 to 2, scaling down custom-deployment-1 from 2 to 0 (keep 2 pods available, don't exceed 3 pods)
    Scaling custom-deployment-1 down to 1
    Scaling custom-deployment-2 up to 2
    Scaling custom-deployment-1 down to 0
--> Success
Complete

사용자 정의 배포 전략 프로세스에서 OpenShift Container Platform API 또는 Kubernetes API에 액세스해야 하는 경우에는 전략을 실행하는 컨테이너에서 인증을 위해 컨테이너 내에 제공되는 서비스 계정 토큰을 사용하면 됩니다.

8.3.4.1. 개발자 화면을 사용하여 배포 편집

개발자 화면을 사용하여 배포 전략, 이미지 설정, 환경 변수 및 배포에 대한 고급 옵션을 편집할 수 있습니다.

사전 요구 사항

  • 웹 콘솔의 개발자 화면에 있습니다.
  • 애플리케이션을 생성했습니다.

프로세스

  1. 토폴로지 보기로 이동합니다.
  2. 애플리케이션을 클릭하여 세부 정보 패널을 확인합니다.
  3. 작업 드롭다운 메뉴에서 배포 편집을 선택하여 배포 편집 페이지를 확인합니다.
  4. 배포에 대한 다음 고급 옵션을 편집할 수 있습니다.

    1. 선택 사항: 롤아웃 일시 중지를 클릭한 다음 이 배포에 대한 Pause 롤아웃 을 선택하여 롤아웃을 일시 중지할 수 있습니다.

      롤아웃을 일시 중지하면 롤아웃을 트리거하지 않고 애플리케이션을 변경할 수 있습니다. 언제든지 롤아웃을 재개할 수 있습니다.

    2. 선택 사항: Replicas 수를 수정하여 이미지 인스턴스 수를 변경하려면 스케일링을 클릭합니다.
  5. 저장을 클릭합니다.

8.3.5. 라이프사이클 후크

롤링 및 재현 전략에서는 라이프사이클 후크 또는 배포 후크를 지원하므로 전략 내의 미리 정의한 지점에서 배포 프로세스에 동작을 삽입할 수 있습니다.

pre 라이프사이클 후크의 예

pre:
  failurePolicy: Abort
  execNewPod: {} 1

1
execNewPod는 Pod 기반 라이프사이클 후크입니다.

모든 후크에는 후크에 오류가 발생했을 때 전략에서 취해야 하는 조치를 정의하는 실패 정책이 있습니다.

Abort

후크가 실패하면 배포 프로세스가 실패로 간주됩니다.

Retry

성공할 때까지 후크를 다시 실행합니다.

Ignore

모든 후크 오류를 무시하고 배포를 계속 진행합니다.

후크에는 후크 실행 방법을 설명하는 유형별 필드가 있습니다. 현재는 Pod 기반 후크가 지원되는 유일한 후크 유형으로 execNewPod필드에 지정되어 있습니다.

Pod 기반 라이프사이클 후크

Pod 기반 라이프사이클 후크는 DeploymentConfig 오브젝트의 템플릿에서 파생된 새 Pod에서 후크 코드를 실행합니다.

간소화된 다음 예제 배포에서는 롤링 전략을 사용합니다. 간결성을 위해 트리거 및 몇 가지 기타 사소한 세부 정보는 생략되었습니다.

kind: DeploymentConfig
apiVersion: apps.openshift.io/v1
metadata:
  name: frontend
spec:
  template:
    metadata:
      labels:
        name: frontend
    spec:
      containers:
        - name: helloworld
          image: openshift/origin-ruby-sample
  replicas: 5
  selector:
    name: frontend
  strategy:
    type: Rolling
    rollingParams:
      pre:
        failurePolicy: Abort
        execNewPod:
          containerName: helloworld 1
          command: [ "/usr/bin/command", "arg1", "arg2" ] 2
          env: 3
            - name: CUSTOM_VAR1
              value: custom_value1
          volumes:
            - data 4
1
helloworld 이름은 spec.template.spec.containers[0].name을 나타냅니다.
2
commandopenshift/origin-ruby-sample 이미지로 정의된 모든 ENTRYPOINT를 재정의합니다.
3
env는 후크 컨테이너의 선택적 환경 변수 세트입니다.
4
volume은 후크 컨테이너의 선택적 볼륨 참조 세트입니다.

이 예제에서 pre 후크는 helloworld 컨테이너의 openshift/origin-ruby-sample 이미지를 사용하여 새 Pod에서 실행됩니다. 후크 Pod에는 다음과 같은 속성이 있습니다.

  • 후크 명령은 /usr/bin/command arg1 arg2입니다.
  • 후크 컨테이너에는 CUSTOM_VAR1=custom_value1 환경 변수가 있습니다.
  • 후크 실패 정책이Abort이므로 후크가 실패하면 배포 프로세스가 실패합니다.
  • 후크 Pod는 DeploymentConfig 오브젝트 Pod의 data 볼륨을 상속합니다.
8.3.5.1. 라이프사이클 후크 설정

CLI를 사용하여 배포에 라이프사이클 후크 또는 배포 후크를 설정할 수 있습니다.

프로세스

  1. oc set deployment-hook 명령을 사용하여 원하는 후크 유형을 --pre, --mid 또는 --post로 설정합니다. 예를 들어 사전 배포 후크를 설정하려면 다음을 실행합니다.

    $ oc set deployment-hook dc/frontend \
        --pre -c helloworld -e CUSTOM_VAR1=custom_value1 \
        --volumes data --failure-policy=abort -- /usr/bin/command arg1 arg2

8.4. 경로 기반 배포 전략 사용

배포 전략에서는 애플리케이션을 개발하는 방식을 제공합니다. 일부 전략에서는 Deployment 오브젝트를 사용하여 애플리케이션으로 확인되는 모든 경로의 사용자에게 표시되는 변경을 수행합니다. 이 섹션에 설명된 것과 같은 기타 고급 전략에서는 Deployment 오브젝트와 함께 라우터 기능을 사용하여 특정 경로에 영향을 미칩니다.

가장 일반적인 경로 기반 전략은 Blue-Green 배포를 사용하는 것입니다. 테스트 및 평가를 위해 새 버전(Green 버전)이 제공되지만 사용자는 여전히 안정적인 버전(Blue 버전)을 사용합니다. 사용자는 준비가 되면 Green 버전으로 전환합니다. 문제가 발생하면 Blue 버전으로 다시 전환할 수 있습니다.

또는 두 버전이 동시에 활성화되는 A/B 버전 전략을 사용할 수 있습니다. 이 전략을 사용하면 일부 사용자는 버전 A 를 사용할 수 있으며 다른 사용자는 버전 B 를 사용할 수 있습니다. 이 전략을 사용하여 사용자 인터페이스 변경 또는 기타 기능을 실험하여 사용자 피드백을 받을 수 있습니다. 또한 문제가 제한된 수의 사용자에게 영향을 미치는 프로덕션 컨텍스트에서 적절한 작업을 확인하는 데 사용할 수도 있습니다.

카나리아 배포는 새 버전을 테스트하지만 문제가 발견되면 신속하게 이전 버전으로 대체합니다. 이는 위의 두 전략 모두에서 수행할 수 있습니다.

경로 기반 배포 전략에서는 서비스의 Pod 수를 확장하지 않습니다. 원하는 성능 특성을 유지 관리하려면 배포 구성을 확장해야 할 수 있습니다.

8.4.1. 프록시 shard 및 트래픽 분할

프로덕션 환경에서는 특정 shard에 전달되는 트래픽 분배를 정확하게 제어할 수 있습니다. 많은 수의 인스턴스를 처리할 때는 개별 shard의 상대적 스케일을 사용하여 백분율 기반 트래픽을 구현할 수 있습니다. 이는 수신하는 트래픽을 다른 곳에서 실행되는 별도의 서비스 또는 애플리케이션으로 전달하거나 분할하는 프록시 shard와 잘 결합합니다.

가장 간단한 구성에서 프록시는 변경되지 않은 요청을 전달합니다. 더 복잡한 설정에서는 들어오는 요청을 복제하여 애플리케이션의 로컬 인스턴스와 별도의 클러스터에 보내 결과를 비교할 수 있습니다. 기타 패턴에는 DR 설치 캐시를 준비 상태로 유지하거나 분석을 위해 들어오는 트래픽을 샘플링하는 작업이 포함됩니다.

모든 TCP(또는 UDP) 프록시는 원하는 shard에서 실행할 수 있습니다. oc scale 명령을 사용하여 프록시 shard에서 요청을 처리하는 상대적 인스턴스 수를 변경합니다. 더 복잡한 트래픽 관리에는 비례 분산 기능을 사용하여 OpenShift Container Platform 라우터를 사용자 정의하는 것이 좋습니다.

8.4.2. N-1 호환성

새 코드와 이전 코드가 동시에 포함된 애플리케이션에서는 새 코드에서 작성한 데이터를 이전 버전의 코드에서 읽고 처리(또는 정상적으로 무시)할 수 있도록 주의해야 합니다. 이는 스키마 진화라고도 하며 복잡한 문제에 해당합니다.

디스크, 데이터베이스, 임시 캐시에 저장된 데이터 또는 사용자 브라우저 세션의 일부 등 다양한 형태를 취할 수 있습니다. 대부분의 웹 애플리케이션에서는 롤링 배포를 지원할 수 있지만 이를 처리할 수 있도록 애플리케이션을 테스트하고 설계하는 것이 중요합니다.

일부 애플리케이션의 경우 이전 코드와 새 코드가 나란히 실행되는 기간이 짧기 때문에 버그 또는 일부 실패한 사용자 트랜잭션이 허용됩니다. 다른 애플리케이션의 경우 실패 패턴으로 인해 전체 애플리케이션이 작동하지 않을 수 있습니다.

N-1 호환성을 검증하는 한 가지 방법은 A/B 배포를 사용하는 것입니다. 즉 테스트 환경에서 제어되는 방식으로 이전 코드와 새 코드를 동시에 실행한 후 새 배포로 이동하는 트래픽으로 인해 이전 배포가 실패하지 않는지 확인하는 것입니다.

8.4.3. 정상적인 종료

OpenShift Container Platform 및 Kubernetes는 부하 분산 순환 작업에서 애플리케이션 인스턴스를 제거하기 전에 종료할 시간을 제공합니다. 그러나 애플리케이션은 종료하기 전에 사용자 연결을 명확하게 종료해야 합니다.

종료 시 OpenShift Container Platform은 컨테이너의 프로세스에 TERM 신호를 보냅니다. 애플리케이션 코드는 SIGTERM을 수신하면 새 연결을 허용하지 않습니다. 이로 인해 로드 밸런서에서 트래픽을 활성 상태의 다른 인스턴스로 라우팅합니다. 그러면 애플리케이션 코드는 열려 있는 모든 연결이 닫힐 때까지 기다리거나 종료되기 전 다음 기회에 개별 연결을 정상적으로 종료합니다.

정상 종료 기간이 만료된 후 종료되지 않은 프로세스에는 KILL 신호가 전송되어 프로세스가 즉시 종료됩니다. Pod 또는 Pod 템플릿의 terminationGracePeriodSeconds 속성은 정상 종료 기간(기본값 30초)을 제어하고 필요에 따라 애플리케이션별로 사용자 지정할 수 있습니다.

8.4.4. Blue-Green 배포

Blue-Green 배포에는 두 가지 버전의 애플리케이션을 동시에 실행하고 프로덕션 내 버전(Blue 버전)에서 최신 버전(Green 버전)으로 트래픽을 이동하는 작업이 포함됩니다. 롤링 전략 또는 전환 서비스를 경로에서 사용할 수 있습니다.

대다수의 애플리케이션이 영구 데이터에 의존하기 때문에 N-1 호환성을 지원하는 애플리케이션이 있어야 합니다. 그러면 데이터 계층 복사본을 두 개 생성하여 데이터를 공유하고 데이터베이스, 저장소 또는 디스크 간 실시간 마이그레이션을 구현할 수 있습니다.

새 버전을 테스트하는 데 사용되는 데이터를 떠올려 보십시오. 데이터가 프로덕션 데이터라면 새 버전의 버그로 인해 프로덕션 버전에 장애가 발생할 수 있습니다.

8.4.4.1. Blue-Green 배포 설정

Blue-Green 배포에서는 두 개의 Deployment 오브젝트를 사용합니다. 둘 다 실행되고 프로덕션의 작업은 경로에서 지정하는 서비스에 따라 달라지며 각 Deployment 오브젝트는 다른 서비스에 노출됩니다.

참고

경로는 웹(HTTP 및 HTTPS) 트래픽을 위한 것이므로 이 기술은 웹 애플리케이션에 적합합니다.

새 버전의 새 경로를 생성하고 테스트할 수 있습니다. 준비되었을 때 새 서비스를 가리키도록 프로덕션 경로의 서비스를 변경하면 새(Green) 버전이 활성화됩니다.

필요한 경우 서비스를 이전 버전(Blue)으로 전환하여 롤백할 수 있습니다.

프로세스

  1. 독립된 애플리케이션 구성 요소 두 개를 생성합니다.

    1. example-blue 서비스에서 v1 이미지를 실행하는 예제 애플리케이션의 복사본을 생성합니다.

      $ oc new-app openshift/deployment-example:v1 --name=example-blue
    2. example-green 서비스에서 v2 이미지를 사용하는 두 번째 복사본을 생성합니다.

      $ oc new-app openshift/deployment-example:v2 --name=example-green
  2. 이전 서비스를 가리키는 경로를 생성합니다.

    $ oc expose svc/example-blue --name=bluegreen-example
  3. bluegreen-example-<project>.<router_domain >에서 애플리케이션을 검색하여 v1 이미지가 표시되는지 확인합니다.
  4. 경로를 편집하고 서비스 이름을 example-green으로 변경합니다.

    $ oc patch route/bluegreen-example -p '{"spec":{"to":{"name":"example-green"}}}'
  5. 경로가 변경되었는지 확인하려면 v2 이미지가 표시될 때까지 브라우저를 새로 고칩니다.

8.4.5. A/B 배포

A/B 배포 전략을 사용하면 프로덕션 환경에서 제한된 방식으로 새 버전의 애플리케이션을 시도할 수 있습니다. 프로덕션 버전에서 대부분의 사용자 요청을 가져오고 제한된 요청만 새 버전으로 이동하도록 지정할 수 있습니다.

각 버전에 대한 요청 분배를 사용자가 제어하므로 테스트를 진행하면서 새 버전에 대한 요청 비율을 늘려 결국 이전 버전의 사용을 중지할 수 있습니다. 각 버전에 대한 요청 부하를 조정할 때 필요한 성능을 제공하기 위해 각 서비스의 Pod 수도 스케일링해야 할 수 있습니다.

소프트웨어 업그레이드 외에도 이 기능을 사용하여 사용자 인터페이스의 버전을 실험할 수 있습니다. 일부 사용자는 이전 버전을 보유하고 있고 일부는 새 버전을 보유하고 있기 때문에 다양한 버전에 대한 사용자의 반응을 평가하여 설계 결정을 알릴 수 있습니다.

이 배포가 효과적이려면 이전 버전과 새 버전이 동시에 실행될 수 있을 정도로 충분히 유사해야 합니다. 버그 수정 릴리즈 및 새 기능이 이전 기능을 방해하지 않는 경우 일반적으로 사용됩니다. 버전이 제대로 작동하려면 N-1 호환성이 필요합니다.

OpenShift Container Platform은 웹 콘솔과 CLI를 통해 N-1 호환성을 지원합니다.

8.4.5.1. A/B 테스트의 부하 분산

사용자는 다양한 서비스를 통해 경로를 설정합니다. 각 서비스는 애플리케이션의 버전을 처리합니다.

각 서비스에는 weight가 할당되고 각 서비스에 대한 일부 요청에는 service_weightsum_of_weights으로 나눈 값이 할당됩니다. 각 서비스의 weight는 서비스 끝점에 분배되므로 끝점 가중치의 합계는 서비스 weight입니다.

이 경로는 최대 4개의 서비스를 제공할 수 있습니다. 서비스 weight0~256 사이일 수 있습니다. weight0 이면 서비스는 부하 분산에 참여하지 않지만 기존 영구 연결을 계속 제공합니다. 서비스 weight0이 아닌 경우 각 끝점의 최소 weight1입니다. 이로 인해 끝점이 많은 서비스는 weight가 의도한 것보다 높을 수 있습니다. 이 경우 Pod 수를 줄이면 예상되는 부하 분산 weight를 얻을 수 있습니다.

프로세스

A/B 환경을 설정하려면 다음을 수행합니다.

  1. 애플리케이션 두 개를 생성하고 서로 다른 이름을 지정합니다. 각각 Deployment 오브젝트를 생성합니다. 두 애플리케이션은 동일한 프로그램의 버전에 해당합니다. 하나는 일반적으로 현재 프로덕션 버전이며 다른 하나는 제안된 새 버전입니다.

    1. 첫 번째 애플리케이션을 생성합니다. 다음 예제에서는 ab-example-a라는 애플리케이션을 생성합니다.

      $ oc new-app openshift/deployment-example --name=ab-example-a
    2. 두 번째 애플리케이션을 생성합니다.

      $ oc new-app openshift/deployment-example:v2 --name=ab-example-b

      두 애플리케이션 모두 배포되고 서비스가 생성됩니다.

  2. 경로를 통해 외부에서 애플리케이션을 사용할 수 있도록 설정합니다. 이 시점에서는 둘 중 하나를 노출할 수 있습니다. 현재 프로덕션 버전을 먼저 노출하고 나중에 경로를 수정하여 새 버전을 추가하는 것이 편리합니다.

    $ oc expose svc/ab-example-a

    ab-example-a.<project>.<router_domain>에서 애플리케이션을 검색하여 예상 버전이 표시되는지 확인합니다.

  3. 경로를 배포할 때 라우터는 서비스에 지정된 weights에 따라 트래픽을 분산합니다. 이 시점에는 기본값이 weight=1인 단일 서비스가 있으므로 모든 요청이 해당 서비스로 이동합니다. 기타 서비스를 alternateBackends로 추가하고 weights를 조정하면 A/B 설정이 활성화됩니다. 이 작업은 oc set route-backends 명령을 실행하거나 경로를 편집하여 수행할 수 있습니다.

    참고

    alternateBackends 를 사용하는 경우 roundrobin 로드 밸런싱 전략을 사용하여 요청이 가중치를 기반으로 서비스에 예상대로 배포되도록 합니다. 경로 주석 을 사용하여 경로에 대해 roundrobin 을 설정할 수 있습니다.

    oc set route-backend0 으로 설정하면 서비스가 부하 분산에 참여하지 않지만 기존 영구 연결을 계속 제공합니다.

    참고

    경로를 변경하면 다양한 서비스에 대한 트래픽 부분만 변경됩니다. 예상되는 부하를 처리하기 위해 Pod 수를 조정하려면 배포를 스케일링해야 할 수 있습니다.

    경로를 편집하려면 다음을 실행합니다.

    $ oc edit route <route_name>

    출력 예

    apiVersion: route.openshift.io/v1
    kind: Route
    metadata:
    metadata:
      name: route-alternate-service
      annotations:
        haproxy.router.openshift.io/balance: roundrobin
    # ...
    spec:
      host: ab-example.my-project.my-domain
      to:
        kind: Service
        name: ab-example-a
        weight: 10
      alternateBackends:
      - kind: Service
        name: ab-example-b
        weight: 15
    # ...

8.4.5.1.1. 웹 콘솔을 사용하여 기존 경로의 가중치 관리

프로세스

  1. 네트워킹경로 페이지로 이동합니다.
  2. 편집할 경로 옆에 있는 작업 메뉴 kebab 를 클릭하고 경로 편집을 선택합니다.
  3. YAML 파일을 편집합니다. 다른 대상 참조 오브젝트에 대한 대상의 상대적 가중치를 지정하는 weight 값을 0에서 256 사이의 정수가 되도록 업데이트합니다. 값 0은 이 백엔드에 대한 요청을 비활성화합니다. 기본값은 100입니다. 옵션에 대한 자세한 내용을 보려면 oc explain routes.spec.alternateBackends를 실행합니다.
  4. 저장을 클릭합니다.
8.4.5.1.2. 웹 콘솔을 사용하여 새 경로의 가중치 관리
  1. 네트워킹경로 페이지로 이동합니다.
  2. 경로 생성을 클릭합니다.
  3. 경로 이름을 입력합니다.
  4. 서비스를 선택합니다.
  5. 대체 서비스 추가를 클릭합니다.
  6. 가중치대체 서비스 가중치 값을 입력합니다. 다른 대상과 비교했을 때 상대적 가중치를 나타내는 0에서 255 사이의 숫자를 입력합니다. 기본값은 100입니다.
  7. 대상 포트를 선택합니다.
  8. Create를 클릭합니다.
8.4.5.1.3. CLI를 사용하여 가중치 관리

절차

  1. 경로에서 부하를 분산하는 서비스와 해당 가중치를 관리하려면 oc set route-backends 명령을 사용합니다.

    $ oc set route-backends ROUTENAME \
        [--zero|--equal] [--adjust] SERVICE=WEIGHT[%] [...] [options]

    예를 들어 다음 명령은 ab-example-aweight=198인 기본 서비스로 설정하고 ab-example-bweight=2인 첫 번째 대체 서비스로 설정합니다.

    $ oc set route-backends ab-example ab-example-a=198 ab-example-b=2

    즉 99%의 트래픽은 서비스 ab-example-a로 전송되고 1%는 서비스 ab-example-b로 전송됩니다.

    이 명령에서는 배포를 스케일링하지 않습니다. 요청 부하를 처리할 수 있는 Pod를 충분히 확보하기 위해서는 스케일링해야 할 수 있습니다.

  2. 플래그 없이 명령을 실행하여 현재 구성을 확인합니다.

    $ oc set route-backends ab-example

    출력 예

    NAME                    KIND     TO           WEIGHT
    routes/ab-example       Service  ab-example-a 198 (99%)
    routes/ab-example       Service  ab-example-b 2   (1%)

  3. 로드 밸런싱 알고리즘의 기본값을 재정의하려면 알고리즘을 roundrobin 으로 설정하여 경로의 주석을 조정합니다. OpenShift Container Platform의 경로의 경우 기본 로드 밸런싱 알고리즘은 random 또는 source 값으로 설정됩니다.

    알고리즘을 roundrobin 으로 설정하려면 다음 명령을 실행합니다.

    $ oc annotate routes/<route-name> haproxy.router.openshift.io/balance=roundrobin

    TLS(Transport Layer Security) 패스스루 경로의 경우 기본값은 source 입니다. 다른 모든 경로의 경우 기본값은 random 입니다.

  4. 자체 또는 기본 서비스에 대한 개별 서비스의 가중치를 변경하려면 --adjust 플래그를 사용합니다. 백분율을 지정하면 기본 또는 첫 번째 대체(기본을 지정하는 경우)를 기준으로 서비스가 조정됩니다. 다른 백엔드가 있는 경우 해당 가중치는 변경된 값에 비례하여 유지됩니다.

    다음 예제에서는 ab-example-aab-example-b 서비스의 가중치를 변경합니다.

    $ oc set route-backends ab-example --adjust ab-example-a=200 ab-example-b=10

    또는 백분율을 지정하여 서비스 가중치를 변경합니다.

    $ oc set route-backends ab-example --adjust ab-example-b=5%

    백분율 선언 앞에 +를 지정하면 현재 설정을 기준으로 가중치를 조정할 수 있습니다. 예를 들면 다음과 같습니다.

    $ oc set route-backends ab-example --adjust ab-example-b=+15%

    --equal 플래그는 모든 서비스의 weight100으로 설정합니다.

    $ oc set route-backends ab-example --equal

    --zero 플래그는 모든 서비스의 weight0으로 설정합니다. 그러면 모든 요청에서 503 오류가 반환됩니다.

    참고

    일부 라우터에서는 다중 또는 가중치 적용 백엔드를 지원하지 않습니다.

8.4.5.1.4. 하나의 서비스, 여러 Deployment 오브젝트

절차

  1. 새 애플리케이션을 생성하여 모든 shard에 공통된 라벨 ab-example=true를 추가합니다.

    $ oc new-app openshift/deployment-example --name=ab-example-a --as-deployment-config=true --labels=ab-example=true --env=SUBTITLE\=shardA
    $ oc delete svc/ab-example-a

    애플리케이션이 배포되고 서비스가 생성됩니다. 이것이 첫 번째 shard입니다.

  2. 경로를 통해 애플리케이션을 사용 가능하게 하거나 서비스 IP를 직접 사용합니다.

    $ oc expose deployment ab-example-a --name=ab-example --selector=ab-example\=true
    $ oc expose service ab-example
  3. ab-example-<project_name>.<router_domain>에서 애플리케이션을 검색하여 v1 이미지가 표시되는지 확인합니다.
  4. 첫 번째 shard와 동일한 소스 이미지 및 라벨을 기반으로 하지만 태그 버전이 다르고 환경 변수가 고유한 두 번째 shard를 생성합니다.

    $ oc new-app openshift/deployment-example:v2 \
        --name=ab-example-b --labels=ab-example=true \
        SUBTITLE="shard B" COLOR="red" --as-deployment-config=true
    $ oc delete svc/ab-example-b
  5. 이 시점에 두 Pod 세트 모두 경로에 제공됩니다. 그러나 두 브라우저(연결을 열린 상태로 유지하여) 및 라우터(기본적으로 쿠키를 통해)에서 백엔드 서버에 대한 연결을 유지하려고 하기 때문에 두 shard가 반환되지 않을 수 있습니다.

    브라우저를 하나 또는 다른 shard에 강제 적용하려면 다음을 수행합니다.

    1. oc scale 명령을 사용하여 ab-example-a의 복제본 수를 0으로 줄입니다.

      $ oc scale dc/ab-example-a --replicas=0

      브라우저를 새로고침하여 v2shard B(빨간색)를 표시합니다.

    2. ab-example-a를 복제본 수 1로, ab-example-b0으로 스케일링합니다.

      $ oc scale dc/ab-example-a --replicas=1; oc scale dc/ab-example-b --replicas=0

      브라우저를 새로고침하여 v1shard A(파란색)를 표시합니다.

  6. 둘 중 하나의 shard에서 배포를 트리거하면 해당 shard의 Pod만 영향을 받습니다. 배포 오브젝트에서 SUBTITLE 환경 변수를 변경하여 배포를 트리거할 수 있습니다.

    $ oc edit dc/ab-example-a

    또는

    $ oc edit dc/ab-example-b

9장. 할당량

9.1. 프로젝트당 리소스 할당량

ResourceQuota 오브젝트로 정의하는 리소스 할당량은 프로젝트당 집계 리소스 사용을 제한하는 제약 조건을 제공합니다. 이를 통해 프로젝트에서 생성할 수 있는 오브젝트의 수량을 유형별로 제한하고 해당 프로젝트의 리소스에서 사용할 수 있는 컴퓨팅 리소스 및 스토리지의 총량도 제한할 수 있습니다.

이 가이드에서는 리소스 할당량이 작동하는 방식, 클러스터 관리자가 프로젝트별로 리소스 할당량을 설정하고 관리하는 방법, 개발자와 클러스터 관리자가 이를 확인하는 방법을 설명합니다.

9.1.1. 할당량으로 관리하는 리소스

다음 내용에서는 할당량으로 관리할 수 있는 컴퓨팅 리소스 및 오브젝트 유형 세트를 설명합니다.

참고

status.phase in (Failed, Succeeded)이 True인 경우 Pod는 터미널 상태에 있습니다.

표 9.1. 할당량으로 관리하는 컴퓨팅 리소스
리소스 이름설명

cpu

터미널이 아닌 상태에서 모든 Pod의 CPU 요청 합계는 이 값을 초과할 수 없습니다. cpurequests.cpu는 동일한 값이며 서로 바꿔 사용할 수 있습니다.

memory

터미널이 아닌 상태에서 모든 Pod의 메모리 요청 합계는 이 값을 초과할 수 없습니다. memoryrequests.memory는 동일한 값이며 서로 바꿔 사용할 수 있습니다.

requests.cpu

터미널이 아닌 상태에서 모든 Pod의 CPU 요청 합계는 이 값을 초과할 수 없습니다. cpurequests.cpu는 동일한 값이며 서로 바꿔 사용할 수 있습니다.

requests.memory

터미널이 아닌 상태에서 모든 Pod의 메모리 요청 합계는 이 값을 초과할 수 없습니다. memoryrequests.memory는 동일한 값이며 서로 바꿔 사용할 수 있습니다.

limits.cpu

터미널이 아닌 상태에서 모든 Pod의 CPU 제한 합계는 이 값을 초과할 수 없습니다.

limits.memory

터미널이 아닌 상태에서 모든 Pod의 메모리 제한 합계는 이 값을 초과할 수 없습니다.

표 9.2. 할당량으로 관리되는 스토리지 리소스
리소스 이름설명

requests.storage

상태와 관계없이 모든 영구 볼륨 클레임의 스토리지 요청 합계는 이 값을 초과할 수 없습니다.

persistentvolumeclaims

프로젝트에 존재할 수 있는 총 영구 볼륨 클레임 수입니다.

<storage-class-name>.storageclass.storage.k8s.io/requests.storage

상태와 관계없이 일치하는 스토리지 클래스가 있는 모든 영구 볼륨 클레임의 스토리지 요청 합계는 이 값을 초과할 수 없습니다.

<storage-class-name>.storageclass.storage.k8s.io/persistentvolumeclaims

프로젝트에 존재할 수 있는, 일치하는 스토리지 클래스가 있는 총 영구 볼륨 클레임 수입니다.

ephemeral-storage

터미널이 아닌 상태에서 모든 Pod의 로컬 임시 스토리지 요청 합계는 이 값을 초과할 수 없습니다. ephemeral-storagerequests.ephemeral-storage는 동일한 값이며 서로 바꿔 사용할 수 있습니다.

requests.ephemeral-storage

터미널이 아닌 상태에서 모든 Pod의 임시 스토리지 요청 합계는 이 값을 초과할 수 없습니다. ephemeral-storagerequests.ephemeral-storage는 동일한 값이며 서로 바꿔 사용할 수 있습니다.

limits.ephemeral-storage

터미널이 아닌 상태에서 모든 Pod의 임시 스토리지 제한 합계는 이 값을 초과할 수 없습니다.

표 9.3. 할당량으로 관리하는 오브젝트 수
리소스 이름설명

pods

프로젝트에 존재할 수 있는 터미널이 아닌 상태의 총 Pod 수입니다.

replicationcontrollers

프로젝트에 존재할 수 있는 총 복제 컨트롤러 수입니다.

resourcequotas

프로젝트에 존재할 수 있는 총 리소스 할당량 수입니다.

services

프로젝트에 존재할 수 있는 총 서비스 수입니다.

services.loadbalancers

프로젝트에 존재할 수 있는 LoadBalancer 유형의 총 서비스 수입니다.

services.nodeports

프로젝트에 존재할 수 있는 NodePort 유형의 총 서비스 수입니다.

secrets

프로젝트에 존재할 수 있는 총 시크릿 수입니다.

configmaps

프로젝트에 존재할 수 있는 총 ConfigMap 오브젝트 수입니다.

persistentvolumeclaims

프로젝트에 존재할 수 있는 총 영구 볼륨 클레임 수입니다.

openshift.io/imagestreams

프로젝트에 존재할 수 있는 총 이미지 스트림 수입니다.

9.1.2. 할당량 범위

각 할당량에는 일련의 관련 범위가 있을 수 있습니다. 특정 할당량은 열거된 범위의 교집합과 일치하는 경우에만 리소스 사용량을 측정합니다.

할당량에 범위를 추가하면 할당량을 적용할 수 있는 리소스 세트가 제한됩니다. 허용된 설정을 벗어난 리소스를 지정하면 검증 오류가 발생합니다.

범위

설명

BestEffort

cpu 또는 memory에 대해 최상의 작업 품질을 제공하는 Pod와 일치합니다.

NotBestEffort

cpumemory에 최상의 작업 품질을 제공하지 않는 Pod와 일치합니다.

BestEffort 범위는 할당량을 제한하여 다음 리소스를 제한합니다.

  • pods

NotBestEffort 범위는 할당량을 제한하여 다음 리소스를 추적합니다.

  • pods
  • memory
  • requests.memory
  • limits.memory
  • cpu
  • requests.cpu
  • limits.cpu

9.1.3. 할당량 적용

프로젝트에 대한 리소스 할당량이 처음 생성되면 프로젝트에서 업데이트된 사용량 통계를 계산할 때까지 할당량 제약 조건을 위반할 수 있는 새 리소스 생성 기능을 제한합니다.

할당량이 생성되고 사용량 통계가 업데이트되면 프로젝트에서 새 콘텐츠 생성을 허용합니다. 리소스를 생성하거나 수정할 때는 리소스 생성 또는 수정 요청에 따라 할당량 사용이 즉시 증가합니다.

리소스를 삭제할 때는 프로젝트에 대한 다음 할당량 통계 전체 재계산 중 할당량 사용이 감소합니다. 구성 가능한 시간에 따라 현재 관찰되는 시스템 값으로 할당량 사용을 줄이는 데 걸리는 시간이 결정됩니다.

프로젝트 수정이 할당량 사용 제한을 초과하면 서버에서 작업을 거부하고 사용자에게 할당량 제약 조건 위반에 대해 설명하는 적절한 오류 메시지와 현재 시스템에서 관찰되는 사용 통계를 반환합니다.

9.1.4. 요청과 제한 비교

컴퓨팅 리소스를 할당할 때 각 컨테이너에서 CPU, 메모리, 임시 스토리지 각각에 대한 요청 및 제한 값을 지정할 수 있습니다. 할당량은 이러한 값 중을 제한할 수 있습니다.

할당량에 requests.cpu 또는 requests.memory에 대해 지정된 값이 있는 경우 들어오는 모든 컨테이너에서 해당 리소스를 명시적으로 요청해야 합니다. 할당량에 limits.cpu 또는 limits.memory에 대해 지정된 값이 있는 경우 들어오는 모든 컨테이너에서 해당 리소스에 대한 제한을 명시적으로 지정해야 합니다.

9.1.5. 리소스 할당량 정의의 예

core-object-counts.yaml

apiVersion: v1
kind: ResourceQuota
metadata:
  name: core-object-counts
spec:
  hard:
    configmaps: "10" 1
    persistentvolumeclaims: "4" 2
    replicationcontrollers: "20" 3
    secrets: "10" 4
    services: "10" 5
    services.loadbalancers: "2" 6

1
프로젝트에 존재할 수 있는 총 ConfigMap 오브젝트 수입니다.
2
프로젝트에 존재할 수 있는 총 PVC(영구 볼륨 클레임) 수입니다.
3
프로젝트에 존재할 수 있는 총 복제 컨트롤러 수입니다.
4
프로젝트에 존재할 수 있는 총 시크릿 수입니다.
5
프로젝트에 존재할 수 있는 총 서비스 수입니다.
6
프로젝트에 존재할 수 있는 LoadBalancer 유형의 총 서비스 수입니다.

openshift-object-counts.yaml

apiVersion: v1
kind: ResourceQuota
metadata:
  name: openshift-object-counts
spec:
  hard:
    openshift.io/imagestreams: "10" 1

1
프로젝트에 존재할 수 있는 총 이미지 스트림 수입니다.

compute-resources.yaml

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources
spec:
  hard:
    pods: "4" 1
    requests.cpu: "1" 2
    requests.memory: 1Gi 3
    limits.cpu: "2" 4
    limits.memory: 2Gi 5

1
프로젝트에 존재할 수 있는 터미널이 아닌 상태의 총 Pod 수입니다.
2
터미널이 아닌 상태에서 모든 Pod의 CPU 요청 합계는 코어 1개를 초과할 수 없습니다.
3
터미널이 아닌 상태에서 모든 Pod의 메모리 요청 합계는 1Gi를 초과할 수 없습니다.
4
터미널이 아닌 상태에서 모든 Pod의 CPU 제한 합계는 코어 2개를 초과할 수 없습니다.
5
터미널이 아닌 상태에서 모든 Pod의 메모리 제한 합계는 2Gi를 초과할 수 없습니다.

besteffort.yaml

apiVersion: v1
kind: ResourceQuota
metadata:
  name: besteffort
spec:
  hard:
    pods: "1" 1
  scopes:
  - BestEffort 2

1
상태가 터미널이 아니고 서비스 품질이 BestEffort인, 프로젝트에 존재할 수 있는 총 Pod 수입니다.
2
메모리 또는 CPU에 대한 서비스 품질이 BestEffort와 일치하는 Pod로만 할당량을 제한합니다.

compute-resources-long-running.yaml

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources-long-running
spec:
  hard:
    pods: "4" 1
    limits.cpu: "4" 2
    limits.memory: "2Gi" 3
  scopes:
  - NotTerminating 4

1
터미널이 아닌 상태의 총 Pod 수입니다.
2
터미널이 아닌 상태에서 모든 Pod의 CPU 제한 합계는 이 값을 초과할 수 없습니다.
3
터미널이 아닌 상태에서 모든 Pod의 메모리 제한 합계는 이 값을 초과할 수 없습니다.
4
할당량을 spec.activeDeadlineSecondsnil로 설정된 일치하는 Pod로만 제한합니다. 빌드 Pod는 RestartNever 정책이 적용되지 않는 한 NotTerminating 에 해당합니다.

compute-resources-time-bound.yaml

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources-time-bound
spec:
  hard:
    pods: "2" 1
    limits.cpu: "1" 2
    limits.memory: "1Gi" 3
  scopes:
  - Terminating 4

1
종료 상태의 총 Pod 수입니다.
2
종료 상태의 모든 Pod에서 CPU 제한 합계는 이 값을 초과할 수 없습니다.
3
종료 상태의 모든 Pod에서 메모리 제한 합계는 이 값을 초과할 수 없습니다.
4
할당량을 spec.activeDeadlineSeconds >=0인 일치하는 Pod로만 제한합니다. 예를 들어 빌드 또는 배포자 Pod에 대한 할당량 비용이 웹 서버 또는 데이터베이스와 같이 오래 실행되는 Pod는 아닙니다.

storage-consumption.yaml

apiVersion: v1
kind: ResourceQuota
metadata:
  name: storage-consumption
spec:
  hard:
    persistentvolumeclaims: "10" 1
    requests.storage: "50Gi" 2
    gold.storageclass.storage.k8s.io/requests.storage: "10Gi" 3
    silver.storageclass.storage.k8s.io/requests.storage: "20Gi" 4
    silver.storageclass.storage.k8s.io/persistentvolumeclaims: "5" 5
    bronze.storageclass.storage.k8s.io/requests.storage: "0" 6
    bronze.storageclass.storage.k8s.io/persistentvolumeclaims: "0" 7
    requests.ephemeral-storage: 2Gi 8
    limits.ephemeral-storage: 4Gi 9

1
프로젝트의 총 영구 볼륨 클레임 수
2
프로젝트의 모든 영구 볼륨 클레임에서 요청된 스토리지 합계는 이 값을 초과할 수 없습니다.
3
프로젝트의 모든 영구 볼륨 클레임에서 골드 스토리지 클래스에 요청된 스토리지 합계는 이 값을 초과할 수 없습니다.
4
프로젝트의 모든 영구 볼륨 클레임에서 실버 스토리지 클래스에 요청된 스토리지 합계는 이 값을 초과할 수 없습니다.
5
프로젝트의 모든 영구 볼륨 클레임에서 실버 스토리지 클래스의 총 클레임 수는 이 값을 초과할 수 없습니다.
6
프로젝트의 모든 영구 볼륨 클레임에서 브론즈 스토리지 클래스에 요청된 스토리지 합계는 이 값을 초과할 수 없습니다. 이 값을 0으로 설정하면 브론즈 스토리지 클래스에서 스토리지를 요청할 수 없습니다.
7
프로젝트의 모든 영구 볼륨 클레임에서 브론즈 스토리지 클래스에 요청된 스토리지 합계는 이 값을 초과할 수 없습니다. 이 값을 0으로 설정하면 브론즈 스토리지 클래스에서 클레임을 생성할 수 없습니다.
8
터미널이 아닌 상태에서 모든 Pod의 임시 스토리지 요청 합계는 2Gi를 초과할 수 없습니다.
9
터미널이 아닌 상태에서 모든 Pod의 임시 스토리지 제한 합계는 4Gi를 초과할 수 없습니다.

9.1.6. 할당량 생성

할당량을 생성하여 지정된 프로젝트에서 리소스 사용량을 제한할 수 있습니다.

프로세스

  1. 파일에 할당량을 정의합니다.
  2. 이 파일을 사용하여 할당량을 생성하고 프로젝트에 적용합니다.

    $ oc create -f <file> [-n <project_name>]

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

    $ oc create -f core-object-counts.yaml -n demoproject
9.1.6.1. 오브젝트 수 할당량 생성

모든 OpenShift Container Platform 표준 네임스페이스 리소스 유형(예: BuildConfig, DeploymentConfig 개체)에 대해 오브젝트 수 할당량을 생성할 수 있습니다. 오브젝트 할당량 수는 모든 표준 네임스페이스 리소스 유형에 정의된 할당량을 지정합니다.

리소스 할당량을 사용할 때 오브젝트는 생성 시 할당량에 대해 부과됩니다. 이러한 유형의 할당량은 스토리지 소진을 방지하는 데 유용합니다. 할당량은 프로젝트 내에 충분한 예비 리소스가 있는 경우에만 생성할 수 있습니다.

프로세스

리소스에 대한 오브젝트 수 할당량을 구성하려면 다음을 수행합니다.

  1. 다음 명령을 실행합니다.

    $ oc create quota <name> \
        --hard=count/<resource>.<group>=<quota>,count/<resource>.<group>=<quota> 1
    1
    <resource> 변수는 리소스 이름이고 <group>은 API 그룹입니다(해당하는 경우). 리소스 및 관련 API 그룹 목록에 oc api-resources 명령을 사용합니다.

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

    $ oc create quota test \
        --hard=count/deployments.extensions=2,count/replicasets.extensions=4,count/pods=3,count/secrets=4

    출력 예

    resourcequota "test" created

    이 예제에서는 나열된 리소스가 클러스터에 있는 각 프로젝트의 하드 제한으로 제한됩니다.

  2. 할당량이 생성되었는지 확인합니다.

    $ oc describe quota test

    출력 예

    Name:                         test
    Namespace:                    quota
    Resource                      Used  Hard
    --------                      ----  ----
    count/deployments.extensions  0     2
    count/pods                    0     3
    count/replicasets.extensions  0     4
    count/secrets                 0     4

9.1.6.2. 확장 리소스에 대한 리소스 할당량 설정

확장 리소스에는 리소스 과다 할당이 허용되지 않으므로 할당량의 해당 확장 리소스에 requestslimits를 지정해야 합니다. 현재는 확장 리소스에 접두사 requests.가 있는 할당량 항목만 허용됩니다. 다음은 GPU 리소스 nvidia.com/gpu에 대한 리소스 할당량을 설정하는 방법에 대한 예제 시나리오입니다.

프로세스

  1. 클러스터의 노드에서 사용 가능한 GPU 수를 결정합니다. 예를 들면 다음과 같습니다.

    # oc describe node ip-172-31-27-209.us-west-2.compute.internal | egrep 'Capacity|Allocatable|gpu'

    출력 예

                        openshift.com/gpu-accelerator=true
    Capacity:
     nvidia.com/gpu:  2
    Allocatable:
     nvidia.com/gpu:  2
      nvidia.com/gpu  0           0

    이 예에서는 GPU 2개를 사용할 수 있습니다.

  2. ResourceQuota 오브젝트를 생성하여 네임스페이스 nvidia 에서 할당량을 설정합니다. 이 예에서 할당량은 1입니다.

    출력 예

    apiVersion: v1
    kind: ResourceQuota
    metadata:
      name: gpu-quota
      namespace: nvidia
    spec:
      hard:
        requests.nvidia.com/gpu: 1

  3. 할당량을 생성합니다.

    # oc create -f gpu-quota.yaml

    출력 예

    resourcequota/gpu-quota created

  4. 네임스페이스에 올바른 할당량이 설정되어 있는지 확인합니다.

    # oc describe quota gpu-quota -n nvidia

    출력 예

    Name:                    gpu-quota
    Namespace:               nvidia
    Resource                 Used  Hard
    --------                 ----  ----
    requests.nvidia.com/gpu  0     1

  5. 단일 GPU를 요청하는 Pod를 정의합니다. 다음 예제 정의 파일은 gpu-pod.yaml이라고 합니다.

    apiVersion: v1
    kind: Pod
    metadata:
      generateName: gpu-pod-
      namespace: nvidia
    spec:
      restartPolicy: OnFailure
      containers:
      - name: rhel7-gpu-pod
        image: rhel7
        env:
          - name: NVIDIA_VISIBLE_DEVICES
            value: all
          - name: NVIDIA_DRIVER_CAPABILITIES
            value: "compute,utility"
          - name: NVIDIA_REQUIRE_CUDA
            value: "cuda>=5.0"
        command: ["sleep"]
        args: ["infinity"]
        resources:
          limits:
            nvidia.com/gpu: 1
  6. Pod를 생성합니다.

    # oc create -f gpu-pod.yaml
  7. Pod가 실행 중인지 확인합니다.

    # oc get pods

    출력 예

    NAME              READY     STATUS      RESTARTS   AGE
    gpu-pod-s46h7     1/1       Running     0          1m

  8. 할당량 Used의 카운터가 올바른지 확인합니다.

    # oc describe quota gpu-quota -n nvidia

    출력 예

    Name:                    gpu-quota
    Namespace:               nvidia
    Resource                 Used  Hard
    --------                 ----  ----
    requests.nvidia.com/gpu  1     1

  9. nvidia 네임스페이스에서 두 번째 GPU Pod를 생성합니다. 노드에 GPU가 2개 있으므로 기술적으로 가능합니다.

    # oc create -f gpu-pod.yaml

    출력 예

    Error from server (Forbidden): error when creating "gpu-pod.yaml": pods "gpu-pod-f7z2w" is forbidden: exceeded quota: gpu-quota, requested: requests.nvidia.com/gpu=1, used: requests.nvidia.com/gpu=1, limited: requests.nvidia.com/gpu=1

    허용되지 않음 오류 메시지는 할당량이 GPU 1개이고 이 Pod에서 할당량을 초과하는 두 번째 GPU를 할당하려고 했기 때문에 예상된 것입니다.

9.1.7. 할당량 보기

웹 콘솔에서 프로젝트의 할당량 페이지로 이동하면 프로젝트 할당량에 정의된 모든 하드 제한과 관련된 사용량 통계를 볼 수 있습니다.

CLI를 사용하여 할당량 세부 정보를 볼 수도 있습니다.

프로세스

  1. 프로젝트에 정의된 할당량 목록을 가져옵니다. 예를 들어 demoproject라는 프로젝트의 경우 다음과 같습니다.

    $ oc get quota -n demoproject

    출력 예

    NAME                           AGE    REQUEST                                                                                                      LIMIT
    besteffort                     4s     pods: 1/2
    compute-resources-time-bound   10m    pods: 0/2                                                                                                    limits.cpu: 0/1, limits.memory: 0/1Gi
    core-object-counts             109s   configmaps: 2/10, persistentvolumeclaims: 1/4, replicationcontrollers: 1/20, secrets: 9/10, services: 2/10

  2. 관심 있는 할당량을 입력합니다. 예를 들어 core-object-counts 할당량은 다음과 같습니다.

    $ oc describe quota core-object-counts -n demoproject

    출력 예

    Name:			core-object-counts
    Namespace:		demoproject
    Resource		Used	Hard
    --------		----	----
    configmaps		3	10
    persistentvolumeclaims	0	4
    replicationcontrollers	3	20
    secrets			9	10
    services		2	10

9.1.8. 명시적 리소스 할당량 구성

새 프로젝트에 특정 리소스 할당량을 적용하려면 프로젝트 요청 템플릿에서 명시적 리소스 할당량을 구성합니다.

사전 요구 사항

  • cluster-admin 역할을 가진 사용자로 클러스터에 액세스합니다.
  • OpenShift CLI(oc)를 설치합니다.

프로세스

  1. 프로젝트 요청 템플릿에 리소스 할당량 정의를 추가합니다.

    • 클러스터에 프로젝트 요청 템플릿이 없는 경우 다음을 수행합니다.

      1. 부트스트랩 프로젝트 템플릿을 생성하고 template.yaml이라는 파일에 출력합니다.

        $ oc adm create-bootstrap-project-template -o yaml > template.yaml
      2. template.yaml에 리소스 할당량 정의를 추가합니다. 다음 예제에서는 'storage-consumption'이라는 리소스 할당량을 정의합니다. 정의는 템플릿의 parameters: 섹션 앞에 추가해야 합니다.

        - apiVersion: v1
          kind: ResourceQuota
          metadata:
            name: storage-consumption
            namespace: ${PROJECT_NAME}
          spec:
            hard:
              persistentvolumeclaims: "10" 1
              requests.storage: "50Gi" 2
              gold.storageclass.storage.k8s.io/requests.storage: "10Gi" 3
              silver.storageclass.storage.k8s.io/requests.storage: "20Gi" 4
              silver.storageclass.storage.k8s.io/persistentvolumeclaims: "5" 5
              bronze.storageclass.storage.k8s.io/requests.storage: "0" 6
              bronze.storageclass.storage.k8s.io/persistentvolumeclaims: "0" 7
        1
        프로젝트의 총 영구 볼륨 클레임 수입니다.
        2
        프로젝트의 모든 영구 볼륨 클레임에서 요청된 스토리지 합계는 이 값을 초과할 수 없습니다.
        3
        프로젝트의 모든 영구 볼륨 클레임에서 골드 스토리지 클래스에 요청된 스토리지 합계는 이 값을 초과할 수 없습니다.
        4
        프로젝트의 모든 영구 볼륨 클레임에서 실버 스토리지 클래스에 요청된 스토리지 합계는 이 값을 초과할 수 없습니다.
        5
        프로젝트의 모든 영구 볼륨 클레임에서 실버 스토리지 클래스의 총 클레임 수는 이 값을 초과할 수 없습니다.
        6
        프로젝트의 모든 영구 볼륨 클레임에서 브론즈 스토리지 클래스에 요청된 스토리지 합계는 이 값을 초과할 수 없습니다. 이 값을 0으로 설정하면 브론즈 스토리지 클래스에서 스토리지를 요청할 수 없습니다.
        7
        프로젝트의 모든 영구 볼륨 클레임에서 브론즈 스토리지 클래스에 요청된 스토리지 합계는 이 값을 초과할 수 없습니다. 이 값을 0으로 설정하면 브론즈 스토리지 클래스에서 클레임을 생성할 수 없습니다.
      3. openshift-config 네임스페이스의 수정된 template.yaml 파일에서 프로젝트 요청 템플릿을 생성합니다.

        $ oc create -f template.yaml -n openshift-config
        참고

        구성을 kubectl.kubernetes.io/last-applied-configuration 주석으로 포함하려면 oc create 명령에 --save-config 옵션을 추가합니다.

        기본적으로 이 템플릿을 project-request라고 합니다.

    • 클러스터에 프로젝트 요청 템플릿이 이미 있는 경우 다음을 수행합니다.

      참고

      구성 파일을 사용하여 클러스터 내의 오브젝트를 선언적 또는 명령적으로 관리하는 경우 대신 해당 파일을 통해 기존 프로젝트 요청 템플릿을 편집합니다.

      1. openshift-config 네임스페이스의 템플릿을 나열합니다.

        $ oc get templates -n openshift-config
      2. 기존 프로젝트 요청 템플릿을 편집합니다.

        $ oc edit template <project_request_template> -n openshift-config
      3. 위의 storage-consumption 예제와 같이 기존 템플릿에 리소스 할당량 정의를 추가합니다. 정의는 템플릿의 parameters: 섹션 앞에 추가해야 합니다.
  2. 프로젝트 요청 템플릿을 생성한 경우 클러스터의 프로젝트 구성 리소스에서 해당 템플릿을 참조합니다.

    1. 편집할 프로젝트 구성 리소스에 액세스합니다.

      • 웹 콘솔 사용:

        1. 관리클러스터 설정으로 이동합니다.
        2. Configuration 을 클릭하여 모든 구성 리소스를 확인합니다.
        3. 프로젝트 항목을 찾아 YAML 편집을 클릭합니다.
      • CLI 사용:

        1. 다음과 같이 project.config.openshift.io/cluster 리소스를 편집합니다.

          $ oc edit project.config.openshift.io/cluster
    2. projectRequestTemplatename 매개변수를 포함하도록 프로젝트 구성 리소스의 spec 섹션을 업데이트합니다. 다음 예제에서는 기본 프로젝트 요청 템플릿 이름 project-request를 참조합니다.

      apiVersion: config.openshift.io/v1
      kind: Project
      metadata:
      #  ...
      spec:
        projectRequestTemplate:
          name: project-request
  3. 프로젝트가 생성될 때 리소스 할당량이 적용되는지 확인합니다.

    1. 프로젝트를 생성합니다.

      $ oc new-project <project_name>
    2. 프로젝트의 리소스 할당량을 나열합니다.

      $ oc get resourcequotas
    3. 리소스 할당량을 자세히 설명합니다.

      $ oc describe resourcequotas <resource_quota_name>

9.2. 다중 프로젝트의 리소스 할당량

ClusterResourceQuota 오브젝트에서 정의하는 다중 프로젝트 할당량은 여러 프로젝트에서 할당량을 공유할 수 있습니다. 선택한 각 프로젝트에서 사용하는 리소스를 집계하고 이 집계 정보를 사용하여 선택한 모든 프로젝트의 리소스를 제한합니다.

이 가이드에서는 클러스터 관리자가 다중 프로젝트에서 리소스 할당량을 설정하고 관리하는 방법을 설명합니다.

9.2.1. 할당량 생성 중 다중 프로젝트 선택

할당량을 생성할 때 주석 선택이나 라벨 선택 또는 둘 다에 따라 다중 프로젝트를 선택할 수 있습니다.

프로세스

  1. 주석에 따라 프로젝트를 선택하려면 다음 명령을 실행합니다.

    $ oc create clusterquota for-user \
         --project-annotation-selector openshift.io/requester=<user_name> \
         --hard pods=10 \
         --hard secrets=20

    이렇게 하면 다음과 같은 ClusterResourceQuota 오브젝트가 생성됩니다.

    apiVersion: quota.openshift.io/v1
    kind: ClusterResourceQuota
    metadata:
      name: for-user
    spec:
      quota: 1
        hard:
          pods: "10"
          secrets: "20"
      selector:
        annotations: 2
          openshift.io/requester: <user_name>
        labels: null 3
    status:
      namespaces: 4
      - namespace: ns-one
        status:
          hard:
            pods: "10"
            secrets: "20"
          used:
            pods: "1"
            secrets: "9"
      total: 5
        hard:
          pods: "10"
          secrets: "20"
        used:
          pods: "1"
          secrets: "9"
    1
    선택한 프로젝트를 통해 적용할 ResourceQuotaSpec 오브젝트입니다.
    2
    주석에 대한 간단한 키-값 선택기입니다.
    3
    프로젝트를 선택하는 데 사용할 수 있는 라벨 선택기입니다.
    4
    선택한 각 프로젝트의 현재 할당량 사용을 설명하는 네임스페이스별 맵입니다.
    5
    선택한 모든 프로젝트에서 집계한 사용량입니다.

    이 다중 프로젝트 할당량 문서는 기본 프로젝트 요청 끝점을 사용하여 <user_name>에서 요청하는 모든 프로젝트를 제어합니다. Pod 10개와 시크릿 20개로 제한되어 있습니다.

  2. 마찬가지로 라벨에 따라 프로젝트를 선택하려면 다음 명령을 실행합니다.

    $  oc create clusterresourcequota for-name \1
        --project-label-selector=name=frontend \2
        --hard=pods=10 --hard=secrets=20
    1
    clusterresourcequotaclusterquota 둘 다 동일한 명령의 별칭입니다. for-nameClusterResourceQuota 오브젝트의 이름입니다.
    2
    라벨에 따라 프로젝트를 선택하려면 --project-label-selector=key=value 형식을 사용하여 키-값 쌍을 제공합니다.

    이렇게 하면 다음과 같은 ClusterResourceQuota 오브젝트 정의가 생성됩니다.

    apiVersion: quota.openshift.io/v1
    kind: ClusterResourceQuota
    metadata:
      creationTimestamp: null
      name: for-name
    spec:
      quota:
        hard:
          pods: "10"
          secrets: "20"
      selector:
        annotations: null
        labels:
          matchLabels:
            name: frontend

9.2.2. 적용 가능한 클러스터 리소스 할당량 보기

프로젝트 관리자는 자신의 프로젝트를 제한하는 다중 프로젝트 할당량을 생성하거나 수정할 수 없지만 관리자는 자신의 프로젝트에 적용되는 다중 프로젝트 할당량 문서를 볼 수 있습니다. 프로젝트 관리자는 AppliedClusterResourceQuota 리소스를 통해 이 작업을 수행할 수 있습니다.

프로세스

  1. 프로젝트에 적용되는 할당량을 보려면 다음을 실행합니다.

    $ oc describe AppliedClusterResourceQuota

    출력 예

    Name:   for-user
    Namespace:  <none>
    Created:  19 hours ago
    Labels:   <none>
    Annotations:  <none>
    Label Selector: <null>
    AnnotationSelector: map[openshift.io/requester:<user-name>]
    Resource  Used  Hard
    --------  ----  ----
    pods        1     10
    secrets     9     20

9.2.3. 선택 단위

할당량 배분을 요청할 때의 잠금 고려 사항으로 인해 다중 프로젝트 할당량에 따라 선택되는 활성 프로젝트의 수는 중요한 고려 사항입니다. 단일 다중 프로젝트 할당량에서 프로젝트를 100개 이상 선택하면 해당 프로젝트의 API 서버 응답성에 불리한 영향을 미칠 수 있습니다.

10장. 애플리케이션과 함께 구성 맵 사용

구성 맵을 사용하면 컨테이너화된 애플리케이션을 이식하기 위해 이미지 콘텐츠와 구성 아티팩트를 분리할 수 있습니다.

다음 섹션에서는 구성 맵과 이를 생성하고 사용하는 방법을 정의합니다.

10.1. 구성 맵 이해

많은 애플리케이션에는 구성 파일, 명령줄 인수 및 환경 변수 조합을 사용하여 구성이 필요합니다. OpenShift Container Platform에서 컨테이너화된 애플리케이션을 이식하기 위해 이러한 구성 아티팩트는 이미지 콘텐츠와 분리됩니다.

ConfigMap 오브젝트는 컨테이너를 OpenShift Container Platform과 무관하게 유지하면서 구성 데이터를 사용하여 컨테이너를 삽입하는 메커니즘을 제공합니다. 구성 맵은 개별 속성 또는 전체 구성 파일 또는 JSON Blob과 같은 세분화된 정보를 저장하는 데 사용할 수 있습니다.

ConfigMap 오브젝트에는 Pod에서 사용하거나 컨트롤러와 같은 시스템 구성 요소의 구성 데이터를 저장하는 데 사용할 수 있는 구성 데이터의 키-값 쌍이 있습니다. 예를 들면 다음과 같습니다.

ConfigMap 오브젝트 정의

kind: ConfigMap
apiVersion: v1
metadata:
  creationTimestamp: 2016-02-18T19:14:38Z
  name: example-config
  namespace: my-namespace
data: 1
  example.property.1: hello
  example.property.2: world
  example.property.file: |-
    property.1=value-1
    property.2=value-2
    property.3=value-3
binaryData:
  bar: L3Jvb3QvMTAw 2

1
구성 데이터를 포함합니다.
2
UTF8이 아닌 데이터를 포함한 파일을 가리킵니다(예: 바이너리 Java 키 저장소 파일). Base 64에 파일 데이터를 입력합니다.
참고

이미지와 같은 바이너리 파일에서 구성 맵을 생성할 때 binaryData 필드를 사용할 수 있습니다.

다양한 방법으로 Pod에서 구성 데이터를 사용할 수 있습니다. 구성 맵을 다음과 같이 사용할 수 있습니다.

  • 컨테이너에서 환경 변수 값 채우기
  • 컨테이너에서 명령줄 인수 설정
  • 볼륨에 구성 파일 채우기

사용자 및 시스템 구성 요소는 구성 데이터를 구성 맵에 저장할 수 있습니다.

구성 맵은 보안과 유사하지만 민감한 정보가 포함되지 않은 문자열 작업을 더 편리하게 지원하도록 설계되었습니다.

구성 맵 제한 사항

Pod에서 콘텐츠를 사용하기 전에 구성 맵을 생성해야 합니다.

컨트롤러는 누락된 구성 데이터를 허용하도록 작성할 수 있습니다. 상황에 따라 구성 맵을 사용하여 구성된 개별 구성 요소를 참조하십시오.

ConfigMap 오브젝트는 프로젝트에 있습니다.

동일한 프로젝트의 Pod에서만 참조할 수 있습니다.

Kubelet은 API 서버에서 가져오는 Pod에 대한 구성 맵만 지원합니다.

여기에는 CLI를 사용하거나 복제 컨트롤러에서 간접적으로 생성되는 모든 Pod가 포함됩니다. OpenShift Container Platform 노드의 --manifest-url 플래그, --config 플래그 또는 해당 REST API를 사용하여 생성한 Pod를 포함하지 않으며 이는 Pod를 생성하는 일반적인 방법이 아니기 때문입니다.

10.2. 사용 사례: Pod에서 구성 맵 사용

다음 섹션에서는 Pod에서 ConfigMap 오브젝트를 사용할 때 몇 가지 사용 사례에 대해 설명합니다.

10.2.1. 구성 맵을 사용하여 컨테이너에서 환경 변수 채우기

구성 맵을 사용하여 컨테이너에서 개별 환경 변수를 채우거나 유효한 환경 변수 이름을 형성하는 모든 키에서 컨테이너의 환경 변수를 채울 수 있습니다.

예를 들어 다음 구성 맵을 고려하십시오.

두 개의 환경 변수가 있는 ConfigMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: special-config 1
  namespace: default 2
data:
  special.how: very 3
  special.type: charm 4

1
구성 맵의 이름입니다.
2
구성 맵이 있는 프로젝트입니다. 구성 맵은 동일한 프로젝트의 Pod에서만 참조할 수 있습니다.
3 4
삽입할 환경 변수입니다.

하나의 환경 변수가 있는 ConfigMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: env-config 1
  namespace: default
data:
  log_level: INFO 2

1
구성 맵의 이름입니다.
2
삽입할 환경 변수입니다.

절차

  • configMapKeyRef 섹션을 사용하여 Pod에서 이 ConfigMap의 키를 사용할 수 있습니다.

    특정 환경 변수를 삽입하도록 구성된 샘플 Pod 사양

    apiVersion: v1
    kind: Pod
    metadata:
      name: dapi-test-pod
    spec:
      containers:
        - name: test-container
          image: gcr.io/google_containers/busybox
          command: [ "/bin/sh", "-c", "env" ]
          env: 1
            - name: SPECIAL_LEVEL_KEY 2
              valueFrom:
                configMapKeyRef:
                  name: special-config 3
                  key: special.how 4
            - name: SPECIAL_TYPE_KEY
              valueFrom:
                configMapKeyRef:
                  name: special-config 5
                  key: special.type 6
                  optional: true 7
          envFrom: 8
            - configMapRef:
                name: env-config 9
      restartPolicy: Never

    1
    ConfigMap에서 지정된 환경 변수를 가져오는 스탠자입니다.
    2
    키 값을 삽입하는 pod 환경 변수의 이름입니다.
    3 5
    특정 환경 변수를 끌어올 ConfigMap의 이름입니다.
    4 6
    ConfigMap에서 가져올 환경 변수입니다.
    7
    환경 변수를 선택적으로 만듭니다. 선택 사항으로 지정된 ConfigMap 및 키가 없는 경우에도 Pod가 시작됩니다.
    8
    ConfigMap에서 모든 환경 변수를 가져오는 스탠자입니다.
    9
    모든 환경 변수를 가져올 ConfigMap의 이름입니다.

    이 Pod가 실행되면 Pod 로그에 다음 출력이 포함됩니다.

    SPECIAL_LEVEL_KEY=very
    log_level=INFO
참고

SPECIAL_TYPE_KEY=charm은 예제 출력에 나열되지 않습니다. optional: true가 설정되어 있기 때문입니다.

10.2.2. 구성 맵을 사용하여 컨테이너 명령에 대한 명령줄 인수 설정

구성 맵을 사용하여 Kubernetes 대체 구문 $(VAR_NAME) 을 사용하여 컨테이너에서 명령 또는 인수 값을 설정할 수 있습니다.

예를 들어 다음 구성 맵을 고려하십시오.

apiVersion: v1
kind: ConfigMap
metadata:
  name: special-config
  namespace: default
data:
  special.how: very
  special.type: charm

절차

  • 컨테이너의 명령에 값을 삽입하려면 환경 변수로 사용할 키를 사용해야 합니다. 그런 다음 $(VAR_NAME) 구문을 사용하여 컨테이너의 명령에서 참조할 수 있습니다.

    특정 환경 변수를 삽입하도록 구성된 샘플 Pod 사양

    apiVersion: v1
    kind: Pod
    metadata:
      name: dapi-test-pod
    spec:
      containers:
        - name: test-container
          image: gcr.io/google_containers/busybox
          command: [ "/bin/sh", "-c", "echo $(SPECIAL_LEVEL_KEY) $(SPECIAL_TYPE_KEY)" ] 1
          env:
            - name: SPECIAL_LEVEL_KEY
              valueFrom:
                configMapKeyRef:
                  name: special-config
                  key: special.how
            - name: SPECIAL_TYPE_KEY
              valueFrom:
                configMapKeyRef:
                  name: special-config
                  key: special.type
      restartPolicy: Never

    1
    환경 변수로 사용할 키를 사용하여 컨테이너의 명령에 값을 삽입합니다.

    이 Pod가 실행되면 test-container 컨테이너에서 실행되는 echo 명령의 출력은 다음과 같습니다.

    very charm

10.2.3. 구성 맵을 사용하여 볼륨에 콘텐츠 삽입

구성 맵을 사용하여 볼륨에 콘텐츠를 삽입할 수 있습니다.

ConfigMap 사용자 정의 리소스(CR)의 예

apiVersion: v1
kind: ConfigMap
metadata:
  name: special-config
  namespace: default
data:
  special.how: very
  special.type: charm

절차

구성 맵을 사용하여 볼륨에 콘텐츠를 삽입하는 몇 가지 다른 옵션이 있습니다.

  • 구성 맵을 사용하여 콘텐츠를 볼륨에 삽입하는 가장 기본적인 방법은 키가 파일 이름이고 파일의 콘텐츠가 키의 값인 파일로 볼륨을 채우는 것입니다.

    apiVersion: v1
    kind: Pod
    metadata:
      name: dapi-test-pod
    spec:
      containers:
        - name: test-container
          image: gcr.io/google_containers/busybox
          command: [ "/bin/sh", "-c", "cat", "/etc/config/special.how" ]
          volumeMounts:
          - name: config-volume
            mountPath: /etc/config
      volumes:
        - name: config-volume
          configMap:
            name: special-config 1
      restartPolicy: Never
    1
    키가 포함된 파일입니다.

    이 Pod가 실행되면 cat 명령의 출력은 다음과 같습니다.

    very
  • 구성 맵 키가 예상되는 볼륨 내의 경로를 제어할 수도 있습니다.

    apiVersion: v1
    kind: Pod
    metadata:
      name: dapi-test-pod
    spec:
      containers:
        - name: test-container
          image: gcr.io/google_containers/busybox
          command: [ "/bin/sh", "-c", "cat", "/etc/config/path/to/special-key" ]
          volumeMounts:
          - name: config-volume
            mountPath: /etc/config
      volumes:
        - name: config-volume
          configMap:
            name: special-config
            items:
            - key: special.how
              path: path/to/special-key 1
      restartPolicy: Never
    1
    구성 맵 키의 경로입니다.

    이 Pod가 실행되면 cat 명령의 출력은 다음과 같습니다.

    very

11장. 개발자 화면을 사용하여 프로젝트 및 애플리케이션 지표 모니터링

개발자 화면의 Observe 보기에서는 프로젝트 또는 애플리케이션 지표(예: CPU, 메모리, 대역폭 사용량, 네트워크 관련 정보)를 모니터링할 수 있는 옵션을 제공합니다.

11.1. 사전 요구 사항

11.2. 프로젝트 지표 모니터링

프로젝트에 애플리케이션을 생성하고 배포한 후 웹 콘솔에서 개발자 화면을 사용하여 프로젝트의 지표를 확인할 수 있습니다.

절차

  1. 모니터링으로 이동하여 프로젝트에 대한 대시보드,지표,경고 및 이벤트를 확인합니다.
  2. 선택 사항: 대시보드 탭을 사용하여 다음 애플리케이션 지표를 표시하는 그래프를 확인합니다.

    • CPU 사용량
    • 메모리 사용량
    • 대역폭 소비
    • 전송 및 수신 패킷의 속도 및 삭제된 패킷 비율과 같은 네트워크 관련 정보입니다.

    대시보드 탭에서 Kubernetes 컴퓨팅 리소스 대시보드에 액세스할 수 있습니다.

    참고

    대시보드 목록에서 Kubernetes / Compute Resources / Namespace (Pods) 대시보드가 기본적으로 선택됩니다.

    자세한 내용을 확인하려면 다음 옵션을 사용합니다.

    • 대시보드 목록에서 대시보드 를 선택하여 필터링된 지표를 확인합니다. 모든 대시보드는 Kubernetes / Compute Resources / Namespace (Pods) 를 제외하고 선택하면 추가 하위 메뉴를 생성합니다.
    • 데이터 캡처 기간을 결정하려면 시간 범위 목록에서 옵션을 선택합니다.
    • 시간 범위 목록에서 사용자 지정 시간 범위를 선택하여 사용자 지정 시간 범위를 설정합니다. 시작 및 종료 날짜 및 시간을 입력하거나 선택할 수 있습니다. 저장을 클릭하여 사용자 지정 시간 범위를 저장합니다.
    • 데이터를 새로 고친 후 기간을 결정하려면 새로 고침 간격 목록에서 옵션을 선택합니다.
    • Pod에 대한 특정 세부 정보를 확인하려면 그래프 위에 커서를 올려놓습니다.
    • 모든 그래프의 오른쪽 상단에 있는 Inspect 를 클릭하여 특정 그래프 세부 정보를 확인합니다. 그래프 세부 정보가 지표 탭에 표시됩니다.
  3. 선택 사항: Metrics 탭을 사용하여 필수 프로젝트 메트릭을 쿼리합니다.

    그림 11.1. 지표 모니터링

    odc project metrics
    1. 쿼리 선택 목록에서 프로젝트에 필요한 세부 정보를 필터링할 옵션을 선택합니다. 프로젝트의 모든 애플리케이션 Pod에 대해 필터링된 지표가 그래프에 표시됩니다. 프로젝트의 Pod도 아래에 나열됩니다.
    2. 쿼리 결과를 추가로 필터링하기 위해 특정 Pod의 지표를 제거하려면 Pod 목록에서 색상이 지정된 사각형 상자를 지웁니다.
    3. Prometheus 쿼리를 보려면 PromQL 표시를 클릭합니다. 쿼리를 사용자 지정하고 해당 네임스페이스에 표시할 지표를 필터링하기 위해 프롬프트의 도움말을 사용하여 이 쿼리를 추가로 수정할 수 있습니다.
    4. 데이터가 표시되는 기간을 설정하려면 드롭다운 목록을 사용합니다. 확대/축소 재설정을 클릭하여 기본 시간 범위를 설정할 수 있습니다.
    5. 선택 사항: 쿼리 선택 목록에서 사용자 정의 쿼리를 선택하여 사용자 정의 Prometheus 쿼리를 생성하고 관련 지표를 필터링합니다.
  4. 선택 사항: 경고 탭을 사용하여 다음 작업을 수행합니다.

    • 프로젝트의 애플리케이션에 대한 경고를 트리거하는 규칙을 참조하십시오.
    • 프로젝트에서 실행되는 경고를 확인합니다.
    • 필요한 경우 이러한 경고를 음소거합니다.

    그림 11.2. 알림 모니터링

    odc project alerts

    자세한 내용을 확인하려면 다음 옵션을 사용합니다.

    • 필터 목록을 사용하여 알림 상태심각도로 알림을 필터링합니다.
    • 알림을 클릭하여 해당 알림의 세부 정보 페이지로 이동합니다. 경고 세부 정보 페이지에서 지표 보기를 클릭하여 경고에 대한 지표를 확인할 수 있습니다.
    • 알림 규칙 옆에 있는 알림 토글을 사용하여 해당 규칙에 대한 모든 알림을 음소거한 다음 음소거 기간 목록에서 알림을 음소거할 기간을 선택합니다. 알림 토글을 보려면 알림을 편집할 수 있는 권한이 있어야 합니다.
    • 경고 규칙 옆에 있는 옵션 메뉴 kebab 를 사용하여 경고 규칙의 세부 정보를 확인합니다.
  5. 선택 사항: 이벤트 탭을 사용하여 프로젝트의 이벤트를 확인합니다.

    그림 11.3. 모니터링 이벤트

    odc project events

    다음 옵션을 사용하여 표시되는 이벤트를 필터링할 수 있습니다.

    • 리소스 목록에서 리소스를 선택하여 해당 리소스에 대한 이벤트를 확인합니다.
    • 모든 유형 목록에서 이벤트 유형을 선택하여 해당 유형과 관련된 이벤트를 확인합니다.
    • 이름 또는 메시지로 이벤트 필터링 필드를 사용하여 특정 이벤트를 검색합니다.

11.3. 애플리케이션 지표 모니터링

프로젝트에 애플리케이션을 생성하고 배포한 후에는 개발자 화면의 토폴로지 보기를 사용하여 애플리케이션에 대한 알림 및 지표를 확인할 수 있습니다. 애플리케이션에 대한 중요 및 경고 알림은 토폴로지 보기의 워크로드 노드에 표시됩니다.

프로세스

워크로드에 대한 알림을 보려면 다음을 수행합니다.

  1. 토폴로지 보기에서 워크로드를 클릭하여 오른쪽 패널의 워크로드 세부 정보를 확인합니다.
  2. Observe 탭을 클릭하여 애플리케이션에 대한 중요 및 경고 경고, 지표(예: CPU, 메모리, 대역폭 사용량)에 대한 그래프, 애플리케이션의 모든 이벤트를 확인합니다.

    참고

    토폴로지 보기에는 실행 중 상태의 중요 및 경고 알림만 표시됩니다. 음소거됨, 보류 중, 실행되지 않음 상태의 알림은 표시되지 않습니다.

    그림 11.4. 애플리케이션 지표 모니터링

    odc app metrics
    1. 오른쪽 패널에 나열된 알림을 클릭하여 알림 세부 정보 페이지에서 알림 세부 정보를 확인합니다.
    2. 차트 중 하나를 클릭하여 지표 탭으로 이동하여 애플리케이션에 대한 세부 지표를 확인합니다.
    3. 모니터링 대시보드 보기를 클릭하여 해당 애플리케이션의 모니터링 대시보드를 확인합니다.

11.4. 이미지 취약점 분석

개발자 화면의 프로젝트 대시보드에는 Status (상태) 섹션에 Image Vulnerabilities (이미지 취약점) 링크가 표시됩니다. 이 링크를 사용하면 취약한 컨테이너 이미지 및 수정 가능한 컨테이너 이미지에 대한 세부 정보가 포함된 이미지 취약점 분석 창을 볼 수 있습니다. 아이콘 색상은 심각도를 나타냅니다.

  • 빨간색: 높은 우선 순위. 즉시 수정되었습니다.
  • 보통: 중간 우선 순위입니다. 높은 우선 순위의 취약점을 수정한 후 수정할 수 있습니다.
  • 노란색: 낮은 우선 순위입니다. 높은 우선 순위의 취약점 및 중간 우선 순위의 취약점을 해결할 수 있습니다.

심각도 수준에 따라 취약점의 우선 순위를 지정하고 체계적인 방식으로 수정할 수 있습니다.

그림 11.5. 이미지 취약점 보기

odc image vulnerabilities

11.5. 애플리케이션 및 이미지 취약점 지표 모니터링

프로젝트에서 애플리케이션을 생성하고 배포한 후 웹 콘솔의 개발자 화면을 사용하여 클러스터 전체에서 애플리케이션 종속성 취약점에 대한 지표를 확인합니다. 메트릭을 사용하면 다음 이미지 취약점을 자세히 분석할 수 있습니다.

  • 선택한 프로젝트의 총 취약한 이미지 수
  • 선택한 프로젝트의 취약한 모든 이미지의 심각도 기반 수
  • 취약점 수, 수정 가능한 취약점 수, 취약한 각 이미지의 영향을 받는 Pod 수와 같은 세부 정보를 얻기 위해 심각도를 드릴다운합니다.

사전 요구 사항

  • Operator Hub에서 Red Hat Quay Container Security Operator를 설치했습니다.

    참고

    Red Hat Quay Container Security Operator는 quay 레지스트리에 있는 이미지를 스캔하여 취약점을 탐지합니다.

절차

  1. 이미지 취약점에 대한 일반적인 개요는 개발자 화면의 탐색 패널에서 Project 를 클릭하여 프로젝트 대시보드를 확인합니다.
  2. 상태 섹션에서 Image Vulnerabilities 을 클릭합니다. 창이 열리면 Vulnerable Container ImagesFixable Container Images 와 같은 세부 정보가 표시됩니다.
  3. 자세한 취약점 개요를 보려면 프로젝트 대시보드에서 Vulnerabilities 탭을 클릭합니다.

    1. 이미지에 대한 자세한 내용을 보려면 해당 이름을 클릭합니다.
    2. 세부 정보 탭의 모든 유형의 취약점과 함께 기본 그래프를 봅니다.
    3. 선택 사항: 토글 버튼을 클릭하여 특정 유형의 취약점을 확인합니다. 예를 들어 앱 종속성 을 클릭하여 애플리케이션 종속성과 관련된 취약점을 확인합니다.
    4. 선택 사항: 심각도 및 유형에 따라 취약점 목록을 필터링하거나 심각도,패키지,유형,소스,현재 버전 수정으로 정렬할 수 있습니다.
    5. 취약점 을 클릭하여 관련 세부 정보를 가져옵니다.

      • 기본 이미지 취약점은 RHSA(Red Hat Security Advisory)의 정보를 표시합니다.
      • 앱 종속성 취약점은 Snyk 보안 애플리케이션의 정보를 표시합니다.

11.6. 추가 리소스

12장. 상태 점검을 사용하여 애플리케이션 상태 모니터링

소프트웨어 시스템에서는 일시적인 문제(예: 일시적인 연결 끊김, 구성 오류 또는 외부 종속 항목의 문제)로 인해 구성 요소가 비정상 상태가 될 수 있습니다. OpenShift Container Platform 애플리케이션에는 비정상 상태의 컨테이너를 탐지하고 처리하는 다양한 옵션이 있습니다.

12.1. 상태 점검 이해

상태 점검에서는 준비 상태, 활성 상태, 시작 상태 점검을 함께 사용하여 실행 중인 컨테이너에서 정기적으로 진단을 수행합니다.

상태 점검을 수행할 컨테이너가 포함된 Pod 사양에 프로브를 1개 이상 포함할 수 있습니다.

참고

기존 Pod에서 상태 점검을 추가하거나 편집하려면 Pod DeploymentConfig 오브젝트를 편집하거나 웹 콘솔에서 개발자 화면을 사용해야 합니다. CLI에서는 기존 Pod의 상태 점검을 추가하거나 편집할 수 없습니다.

Readiness 프로브

준비 상태 프로브는 컨테이너가 서비스 요청을 수락할 준비가 되었는지 확인합니다. 컨테이너에 대한 준비 상태 프로브가 실패하면 kubelet에서 사용 가능한 서비스 끝점 목록에서 Pod를 제거합니다.

프로브는 실패 후에도 Pod를 계속 검사합니다. Pod를 사용할 수 있게 되면 kubelet은 사용 가능한 서비스 끝점 목록에 Pod를 추가합니다.

활성 상태 점검

활성 상태 프로브는 컨테이너가 계속 실행 중인지 확인합니다. 교착 상태와 같은 상태로 인해 활성 상태 프로브가 실패하면 kubelet에서 컨테이너를 종료합니다. 그런 다음 Pod는 재시작 정책에 따라 작업을 수행합니다.

예를 들어 restartPolicyAlways 또는 OnFailure인 Pod의 활성 상태 프로브는 컨테이너를 종료한 후 다시 시작합니다.

Startup 프로브

시작 프로브는 컨테이너 내 애플리케이션이 시작되었는지를 나타냅니다. 기타 모든 프로브는 시작 프로브가 성공할 때까지 비활성화됩니다. 시작 프로브가 지정된 기간 내에 성공하지 못하면 kubelet에서 컨테이너를 종료하고 컨테이너에 Pod의 restartPolicy가 적용됩니다.

일부 애플리케이션에는 첫 번째 초기화 시 추가 시작 시간이 필요할 수 있습니다. 시작 프로브를 활성 상태 또는 준비 상태 프로브와 함께 사용하면 failureThresholdperiodSeconds 매개변수로 해당 프로브를 충분히 연기하여 긴 시작 시간을 처리할 수 있습니다.

예를 들어 실패 30회의 failureThreshold와 10초의 periodSeconds를 사용하면(30 * 10s = 300s) 최대 5분 동안 시작 프로브를 활성 상태 프로브에 추가할 수 있습니다. 시작 프로브가 처음으로 성공하면 활성 상태 프로브가 시작됩니다.

다음과 같은 테스트 유형을 사용하여 활성 상태 프로브, 준비 상태 프로브, 시작 프로브를 구성할 수 있습니다.

  • HTTP GET: HTTP GET 테스트를 사용하면 테스트에서 웹 후크를 사용하여 컨테이너의 상태를 확인합니다. HTTP 응답 코드가 200에서 399 사이인 경우 테스트가 성공한 것입니다.

    HTTP GET 테스트는 완전히 초기화되었을 때 HTTP 상태 코드를 반환하는 애플리케이션에 사용할 수 있습니다.

  • 컨테이너 명령: 컨테이너 명령 테스트를 사용할 때 프로브가 컨테이너 내에서 명령을 실행합니다. 테스트가 상태 0으로 종료되면 프로브가 성공한 것입니다.
  • TCP 소켓: TCP 소켓 테스트를 사용하면 프로브에서 컨테이너에 대한 소켓을 열려고 합니다. 컨테이너는 프로브에서 연결을 설정할 수 있는 경우에만 정상 상태로 간주됩니다. TCP 소켓 테스트는 초기화가 완료된 후 수신 대기를 시작하는 애플리케이션에 사용할 수 있습니다.

다음과 같은 다양한 필드를 구성하여 프로브 동작을 제어할 수 있습니다.

  • initialDelaySeconds: 컨테이너를 시작한 후 프로브를 예약할 수 있을 때까지의 시간(초)입니다. 기본값은 0입니다.
  • periodSeconds: 프로브 수행 사이의 지연 시간(초)입니다. 기본값은 10입니다. 이 값은 timeoutSeconds 보다 커야 합니다.
  • timeoutSeconds: 프로브가 타임아웃되고 컨테이너가 실패한 것으로 간주되는 비활성 시간(초)입니다. 기본값은 1입니다. 이 값은 periodSeconds 보다 작아야 합니다.
  • successThreshold: 실패 후 컨테이너 상태를 성공으로 재설정하기 위해 프로브에서 성공을 보고해야 하는 횟수입니다. 활성 상태 프로브는 값이 1이어야 합니다. 기본값은 1입니다.
  • failureThreshold: 프로브가 실패할 수 있는 횟수입니다. 기본값은 3입니다. 지정된 시도 횟수 후에는 다음이 수행됩니다.

    • 활성 상태 프로브의 경우 컨테이너가 재시작됩니다.
    • 준비 상태 프로브의 경우 Pod가 Unready로 표시됩니다.
    • 시작 프로브의 경우 컨테이너가 종료되고 Pod의 restartPolicy가 적용됩니다.
프로브 예

다음은 오브젝트 사양에 나타나는 다양한 프로브 샘플입니다.

Pod 사양에 컨테이너 명령 준비 상태 프로브가 포함된 샘플 준비 상태 프로브

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: health-check
  name: my-application
# ...
spec:
  containers:
  - name: goproxy-app 1
    args:
    image: registry.k8s.io/goproxy:0.1 2
    readinessProbe: 3
      exec: 4
        command: 5
        - cat
        - /tmp/healthy
# ...

1
컨테이너 이름입니다.
2
배포할 컨테이너 이미지입니다.
3
Readiness 프로브입니다.
4
컨테이너 명령 테스트입니다.
5
컨테이너에서 실행할 명령입니다.

Pod 사양에 컨테이너 명령 테스트가 포함된 샘플 컨테이너 명령 시작 프로브 및 활성 상태 프로브

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: health-check
  name: my-application
# ...
spec:
  containers:
  - name: goproxy-app 1
    args:
    image: registry.k8s.io/goproxy:0.1 2
    livenessProbe: 3
      httpGet: 4
        scheme: HTTPS 5
        path: /healthz
        port: 8080 6
        httpHeaders:
        - name: X-Custom-Header
          value: Awesome
    startupProbe: 7
      httpGet: 8
        path: /healthz
        port: 8080 9
      failureThreshold: 30 10
      periodSeconds: 10 11
# ...

1
컨테이너 이름입니다.
2
배포할 컨테이너 이미지를 지정합니다.
3
활성 상태 프로브
4
HTTP GET 테스트입니다.
5
인터넷 스키마(HTTP 또는 HTTPS)입니다. 기본값은 HTTP입니다.
6
컨테이너가 수신 대기 중인 포트입니다.
7
시작 프로브입니다.
8
HTTP GET 테스트입니다.
9
컨테이너가 수신 대기 중인 포트입니다.
10
실패 후 프로브에 시도할 수 있는 횟수입니다.
11
프로브를 수행할 시간(초)입니다.

Pod 사양의 타임아웃을 사용하는 컨테이너 명령 테스트가 포함된 샘플 활성 상태 프로브

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: health-check
  name: my-application
# ...
spec:
  containers:
  - name: goproxy-app 1
    args:
    image: registry.k8s.io/goproxy:0.1 2
    livenessProbe: 3
      exec: 4
        command: