Documentation

8. 컨테이너 및 인스턴스 그룹

컨트롤러를 사용하면 컨테이너 그룹이라는 필수 서비스 계정이 프로비저닝된 Openshift 클러스터의 네임스페이스 또는 클러스터의 멤버에서 ansible 플레이북 실행을 통해 직접 작업을 실행할 수 있습니다. 컨테이너 그룹에서 플레이북당 필요한 만큼만 작업을 실행할 수 있습니다. 자세한 내용은 이 섹션의 끝에 있는 :ref:`ag_container_groups`을 참조하십시오.

|ees|의 경우 |atu|에서 :ref:`ug_execution_environments`을 참조하십시오.

8.1. 인스턴스 그룹

인스턴스를 하나 이상의 인스턴스 그룹으로 그룹화할 수 있습니다. 아래에 있는 하나 이상의 리소스에 인스턴스 그룹을 할당할 수 있습니다.

  • 조직

  • 인벤토리

  • 작업 템플릿

리소스 중 하나와 연결된 작업이 실행되면 해당 리소스와 연결된 인스턴스 그룹에 작업이 할당됩니다. 실행 프로세스 중 작업 템플릿과 연결된 인스턴스 그룹이 인벤토리와 연결된 인스턴스 그룹보다 먼저 확인됩니다. 마찬가지로, 인벤토리와 연결된 인스턴스 그룹이 조직과 연결된 인스턴스 그룹보다 먼저 확인됩니다. 따라서 3개 리소스에 대한 인스턴스 그룹 할당은 작업 템플릿 > 인벤토리 > 조직 계층을 형성합니다.

다음은 인스턴스 그룹 작업 시 고려해야 할 몇 가지 사항입니다.

  • 인스턴스 그룹에서 다른 그룹 및 그룹 인스턴스를 선택적으로 정의할 수 있습니다. 이러한 그룹의 앞에는 instance_group_ 접두사가 붙어야 합니다. 다른 instance_group_ 그룹과 함께 automationcontroller 또는 execution_nodes 그룹에 인스턴스가 있어야 합니다. 클러스터형 설정에서는 automationcontroller 그룹에 하나 이상의 인스턴스가 반드시 있어야 합니다. 해당 인스턴스는 API 인스턴스 그룹에서 ``controlplane``으로 표시됩니다. 예제 시나리오는 :ref:`ag_automationcontroller_group_policies`을 참조하십시오.

  • default API 인스턴스 그룹은 작업을 실행할 수 있는 모든 노드를 사용하여 자동으로 생성됩니다. 기술적으로는 다른 인스턴스 그룹과 유사하지만, 특정 인스턴스 그룹이 특정 리소스와 연결되지 않은 경우 작업 실행이 항상 default 인스턴스 그룹으로 대체됩니다. default 인스턴스 그룹은 항상 있으며 삭제하거나 이름을 변경할 수 없습니다.

  • ``instance_group_default``라는 그룹을 생성하지 마십시오.

  • 그룹 이름과 동일한 인스턴스 이름을 지정하지 마십시오.

8.1.1. automationcontroller 그룹 정책

노드를 정의할 때는 다음 기준을 사용합니다.

  • automationcontroller 그룹의 노드는 node_type hostvar을 ``hybrid``(기본값) 또는 ``control``로 정의할 수 있습니다.

  • execution_nodes 그룹의 노드는 node_type hostvar을 ``execution``(기본값) 또는 ``hop``으로 정의할 수 있습니다.

``instance_group_*``로 그룹 이름을 지정하여 인벤토리 파일에서 사용자 지정 그룹을 정의할 수 있습니다. 여기서 ``*``는 API의 그룹 이름이 됩니다. 또는 설치가 완료된 후 API에서 사용자 지정 인스턴스 그룹을 생성할 수 있습니다.

현재 동작에서는 instance_group_*``의 멤버가 ``automationcontroller 또는 execution_nodes 그룹에 속해야 합니다. 다음 예제 시나리오를 참조하십시오.

[automationcontroller]
126-addr.tatu.home ansible_host=192.168.111.126  node_type=control

[automationcontroller:vars]
peers=execution_nodes

[execution_nodes]

[instance_group_test]
110-addr.tatu.home ansible_host=192.168.111.110 receptor_listener_port=8928

설치 프로그램을 실행하면 다음과 같은 오류가 발생합니다.

TASK [ansible.automation_platform_installer.check_config_static : Validate mesh topology] ***
fatal: [126-addr.tatu.home -> localhost]: FAILED! => {"msg": "The host '110-addr.tatu.home' is not present in either [automationcontroller] or [execution_nodes]"}

이 오류를 해결하려면 110-addr.tatu.home 박스를 execution_node 그룹으로 이동하면 됩니다.

[automationcontroller]
126-addr.tatu.home ansible_host=192.168.111.126  node_type=control

[automationcontroller:vars]
peers=execution_nodes

[execution_nodes]
110-addr.tatu.home ansible_host=192.168.111.110 receptor_listener_port=8928

[instance_group_test]
110-addr.tatu.home

결과는 다음과 같습니다.

TASK [ansible.automation_platform_installer.check_config_static : Validate mesh topology] ***
ok: [126-addr.tatu.home -> localhost] => {"changed": false, "mesh": {"110-addr.tatu.home": {"node_type": "execution", "peers": [], "receptor_control_filename": "receptor.sock", "receptor_control_service_name": "control", "receptor_listener": true, "receptor_listener_port": 8928, "receptor_listener_protocol": "tcp", "receptor_log_level": "info"}, "126-addr.tatu.home": {"node_type": "control", "peers": ["110-addr.tatu.home"], "receptor_control_filename": "receptor.sock", "receptor_control_service_name": "control", "receptor_listener": false, "receptor_listener_port": 27199, "receptor_listener_protocol": "tcp", "receptor_log_level": "info"}}}

컨트롤러 4.0 이하에서 업그레이드 시 레거시 instance_group_ 멤버에 awx 코드가 설치되어 해당 노드가 automationcontroller 그룹에 배치될 가능성이 큽니다.

8.1.2. API에서 인스턴스 그룹 구성

시스템 관리자로 ``/api/v2/instance_groups``에 POST를 수행하면 인스턴스 그룹을 생성할 수 있습니다.

생성된 인스턴스는 다음을 사용하여 인스턴스 그룹과 연결할 수 있습니다.

HTTP POST /api/v2/instance_groups/x/instances/ {'id': y}`

인스턴스 그룹에 추가된 인스턴스는 그룹의 작업 큐에서 수신 대기하도록 자동으로 재구성됩니다. 자세한 내용은 인스턴스 그룹 정책 섹션을 참조하십시오.

8.1.3. 인스턴스 그룹 정책

:term:`policy`를 정의하여 온라인 상태의 인스턴스 그룹에 자동으로 참여하도록 컨트롤러 인스턴스를 구성할 수 있습니다. 이러한 정책은 온라인 상태의 모든 새 인스턴스를 대상으로 평가됩니다.

인스턴스 그룹 정책은 ``Instance Group``의 세 가지 선택 필드로 제어됩니다.

  • policy_instance_percentage: 0에서 100 사이의 숫자입니다. 이 백분율의 활성 컨트롤러 인스턴스가 이 인스턴스 그룹에 추가됩니다. 새 인스턴스가 온라인 상태가 될 때 총 인스턴스 수와 비교해 이 그룹의 인스턴스 수가 지정된 백분율보다 작으면 백분율 조건이 충족될 때까지 새 인스턴스가 추가됩니다.

  • policy_instance_minimum: 이 정책은 인스턴스 그룹의 인스턴스 수를 이 값 이상으로 유지하려고 합니다. 사용 가능한 인스턴스 수가 이 최소값보다 작으면 모든 인스턴스가 이 인스턴스 그룹에 배치됩니다.

  • policy_instance_list: 이 인스턴스 그룹에 항상 포함할 인스턴스 이름의 고정 목록입니다.

automation controller 사용자 인터페이스의 인스턴스 그룹 목록 뷰는 인스턴스 그룹 정책에 따른 각 인스턴스 그룹의 용량 수준을 요약해서 보여 줍니다.

Instance Group policy example

8.1.4. 주요 정책 고려 사항

  • ``policy_instance_percentage``와 ``policy_instance_minimum``은 둘 다 최소 할당 값을 설정합니다. 그룹에 더 많은 인스턴스가 할당되게 하는 규칙이 적용됩니다. 예를 들어 ``policy_instance_percentage``가 50%이고 ``policy_instance_minimum``이 2인 경우 6개 인스턴스를 시작하면 3개 인스턴스가 인스턴스 그룹에 할당됩니다. 클러스터의 총 인스턴스 수를 2개로 줄이면 ``policy_instance_minimum``을 충족하기 위해 둘 다 인스턴스 그룹에 할당됩니다. 이렇게 하면 사용 가능한 리소스 양에 하한을 설정할 수 있습니다.

  • 정책을 적용하더라도 인스턴스가 여러 인스턴스 그룹과 연결되는 것을 적극적으로 차단하지는 않지만 백분율 합계를 100으로 만들면 효과적으로 차단할 수 있습니다. 4개의 인스턴스 그룹이 있는 경우 각 그룹에 백분율 값 25를 할당하면 인스턴스가 겹치지 않고 그룹 간에 배포됩니다.

8.1.5. 인스턴스를 특정 그룹에 수동으로 고정

특정 인스턴스 그룹에 배타적으로 할당되어야 하는 특수 인스턴스가 있지만 《백분율》 또는 《최소값》 정책을 통해 다른 그룹에 자동으로 참여하지 않도록 하려면 다음을 수행합니다.

  1. 하나 이상 인스턴스 그룹의 ``policy_instance_list``에 인스턴스를 추가합니다.

  2. 인스턴스의 managed_by_policy 속성을 ``False``로 업데이트합니다.

이렇게 하면 인스턴스가 백분율 및 최소값 정책에 따라 다른 그룹에 자동으로 추가되지 않고 수동으로 할당한 그룹에만 속하게 됩니다.

HTTP PATCH /api/v2/instance_groups/N/
{
"policy_instance_list": ["special-instance"]
}

HTTP PATCH /api/v2/instances/X/
{
"managed_by_policy": False
}

8.1.6. 작업 런타임 동작

인스턴스 그룹과 연결된 작업을 실행할 때 주목할 만한 몇 가지 동작은 다음과 같습니다.

  • 클러스터가 개별 인스턴스 그룹으로 나누어져 있는 경우 클러스터 전체와 비슷하게 작동합니다. 두 인스턴스가 하나의 그룹에 할당된 경우 둘 중 하나는 동일한 그룹의 다른 인스턴스만큼 작업을 받을 가능성이 큽니다.

  • 컨트롤러 인스턴스가 온라인 상태가 되면 시스템의 작업 용량이 효과적으로 확장됩니다. 이러한 인스턴스가 인스턴스 그룹에도 배치되는 경우 해당 그룹의 용량도 확장됩니다. 인스턴스가 작업을 수행하고 여러 그룹의 멤버인 경우 인스턴스가 속한 모든 그룹에서 용량이 줄어듭니다. 인스턴스를 프로비저닝 해제하면 인스턴스가 어디에서 할당되었든 클러스터 용량이 제거됩니다. 자세한 내용은 인스턴스 프로비저닝 해제 섹션을 참조하십시오.

참고

모든 인스턴스를 동일한 용량으로 프로비저닝해야 하는 것은 아닙니다.

8.1.7. 작업이 실행되는 위치 제어

작업 템플릿, 인벤토리 또는 조직에 인스턴스 그룹이 연결된 경우 해당 작업 템플릿에서 실행된 작업은 기본 동작을 수행할 수 없습니다. 즉, 이 3개 리소스와 연결된 인스턴스 그룹 내의 모든 인스턴스에 용량이 부족하면 용량을 사용할 수 있을 때까지 작업이 보류 상태로 유지됩니다.

작업을 제출할 인스턴스 그룹을 결정하는 기본 설정 순서는 다음과 같습니다.

  1. 작업 템플릿

  2. 인벤토리

  3. 조직(프로젝트를 통해)

인스턴스 그룹이 작업 템플릿과 연결되어 있고 모든 그룹이 한도에 도달하면 인벤토리, 조직에서 차례로 지정된 인스턴스 그룹에 작업이 제출됩니다. 해당 그룹에서는 리소스를 사용할 수 있으므로 작업이 기본 설정 순서대로 실행됩니다.

글로벌 default 그룹은 플레이북에 정의된 사용자 지정 인스턴스 그룹과 마찬가지로 계속 리소스와 연결될 수 있습니다. 이 그룹을 사용하여 작업 템플릿 또는 인벤토리의 기본 설정 인스턴스 그룹을 지정할 수 있지만, 이 경우에도 용량이 부족하면 작업이 아무 인스턴스에나 제출될 수 있습니다.

예를 들어 group_a``를 작업 템플릿과 연결하고 ``default 그룹도 해당 인벤토리와 연결하면 group_a``의 용량이 부족할 경우 ``default 그룹이 대체로 사용될 수 있습니다.

또한 인스턴스 그룹을 하나의 리소스와 연결하지 않고 다른 리소스를 대체로 지정할 수 있습니다. 예를 들어 인스턴스 그룹을 작업 템플릿과 연결하지 않고 인벤토리 및/또는 조직의 인스턴스 그룹으로 대체되도록 합니다.

이런 방식의 다른 두 가지 주요 사용 사례는 다음과 같습니다.

  1. 인스턴스 그룹에 작업 템플릿을 할당하지 않고 인스턴스 그룹을 인벤토리와 연결하면 사용자는 특정 인벤토리에 실행되는 플레이북이 해당 인벤토리와 연결된 그룹에서만 실행되도록 할 수 있습니다. 이 기능은 관리형 노드에 연결된 직접 링크가 해당 인스턴스에만 있는 경우 매우 유용할 수 있습니다.

  2. 관리자는 조직에 인스턴스 그룹을 할당할 수 있습니다. 이렇게 하면 관리자가 효과적으로 전체 인프라를 분할하여 작업 실행 용량이 각 조직에 확보되도록 할 수 있습니다. 이때 다른 조직의 작업 실행 능력은 저해되지 않습니다.

마찬가지로, 관리자는 다음 시나리오에서처럼 각 조직에 여러 그룹을 원하는 대로 할당할 수 있습니다.

  • 인스턴스 그룹 3개(A, B, C)와 조직 2개(Org1, Org2)가 있습니다.

  • 관리자가 Org1에 그룹 A, Org2에 그룹 B를 할당한 다음, 필요할 수 있는 추가 용량을 위한 오버플로로 Org1과 Org2 둘 다에 그룹 C를 할당합니다.

  • 그러면 조직 관리자가 원하는 그룹에 인벤토리 또는 작업 템플릿을 자유롭게 할당하거나 조직에서 기본 순서를 가져오도록 할 수 있습니다.

Instance Group example

이런 방식으로 리소스를 배치하면 상당히 유연하게 작업할 수 있습니다. 또한 하나의 인스턴스만으로 인스턴스 그룹을 생성할 수 있으므로 컨트롤러 클러스터의 매우 구체적인 호스트로 작업을 보낼 수 있습니다.

8.1.8. 인스턴스 그룹 프로비저닝 해제

현재 클러스터는 의도적으로 또는 오류로 인해 오프라인 상태로 전환된 인스턴스를 구분하지 않으므로 설정 플레이북을 다시 실행해도 인스턴스가 자동으로 프로비저닝 해제되지는 않습니다. 대신 컨트롤러 인스턴스에서 모든 서비스를 종료한 다음, 다른 인스턴스에서 프로비저닝 해제 툴을 실행합니다.

  1. automation-controller-service stop 명령을 사용하여 인스턴스를 종료하거나 서비스를 중지합니다.

  2. 다른 인스턴스에서 프로비저닝 해제 명령 ``$ awx-manage deprovision_instance –hostname=<name used in inventory file>``을 실행하여 컨트롤러 클러스터 레지스트리에서 제거합니다.

    예: awx-manage deprovision_instance --hostname=hostB

마찬가지로, 컨트롤러에서 인스턴스 그룹을 프로비저닝 해제해도 인스턴스 그룹이 자동으로 프로비저닝 해제되거나 제거되지는 않지만 다시 프로비저닝할 때 해당 인스턴스 그룹이 사용되지 않는 경우가 많습니다. API 끝점 및 통계 모니터링에는 인스턴스 그룹이 계속 표시될 수도 있습니다. 다음 명령을 사용하면 이러한 그룹을 제거할 수 있습니다.

예: awx-manage unregister_queue --queuename=<name>

인벤토리 파일의 인스턴스 그룹에서 인스턴스 멤버십을 제거하고 설정 플레이북을 다시 실행하면 인스턴스가 그룹에 다시 추가될 수도 있습니다. 인스턴스가 그룹에 다시 추가되지 않도록 하려면 API를 통해 제거하고 인벤토리 파일에서도 제거하면 됩니다. 또는 인벤토리 파일에서 인스턴스 그룹 정의를 완전히 중지해도 됩니다. automation controller 사용자 인터페이스를 통해 인스턴스 그룹 토폴로지를 관리할 수도 있습니다. UI에서 인스턴스 그룹을 관리하는 방법에 대한 자세한 내용은 |atu|에서 :ref:`Instance Groups <userguide:ug_instance_groups>`을 참조하십시오.

참고

이전 버전의 컨트롤러(3.8.x 이하)에서 생성된 격리 인스턴스 그룹이 있고 이 그룹을 실행 노드로 마이그레이션하여 자동화 메시 아키텍처에서 사용할 수 있게 하려면 |atumg|에서 :ref:`migrate_iso_to_exe`을 참조하십시오.

8.2. 컨테이너 그룹

|aap|에서는 컨트롤러가 독립 실행형으로 설치되었는지, 가상 환경 또는 컨테이너에 설치되었는지와 관계없이 컨트롤러에서 작업을 실행할 수 있도록 :term:`Container Groups`을 지원합니다. 컨테이너 그룹은 가상 환경 내에서 리소스 풀 역할을 합니다. 플레이북을 실행하는 동안에만 존재하는 Pod로 요구에 따라 프로비저닝되는 작업 환경인 OpenShift 컨테이너를 가리키는 인스턴스 그룹을 생성할 수 있습니다. 이를 임시 실행 모델이라고 하며, 모든 작업이 새 환경에서 실행되도록 합니다.

경우에 따라 컨테이너 그룹을 《상시》로 설정하는 것이 좋으며, 이 상태는 인스턴스를 생성하여 구성합니다.

참고

automation controller 4.0 이전 버전에서 업그레이드된 컨테이너 그룹은 다시 기본값으로 복원되고 이전 Pod 정의를 완전히 제거하므로 마이그레이션에 포함된 모든 사용자 지정 Pod 정의가 지워집니다.

컨테이너 그룹은 |ees|과 다릅니다. |ees|은 컨테이너 이미지이며 가상 환경을 사용하지 않기 때문입니다. 자세한 내용은 |atu|에서 :ref:`ug_execution_environments`을 참조하십시오.

8.2.1. 컨테이너 그룹 생성

ContainerGroup``은 OpenShift 클러스터에 연결할 있는 관련 인증 정보가 있는 ``InstanceGroup 유형입니다. 컨테이너 그룹을 설정하려면 먼저 다음이 있어야 합니다.

  • 시작할 수 있는 네임스페이스(클러스터마다 《기본》 네임스페이스가 있지만 특정 네임스페이스를 사용할 수 있습니다.)

  • 이 네임스페이스의 Pod를 시작하고 관리할 수 있는 역할이 있는 서비스 계정

  • 프라이빗 레지스트리에서 |ees|을 사용하고 이 환경에 연결된 컨테이너 레지스트리 인증 정보가 자동화 컨트롤러에 있는 경우 네임스페이스에서 비밀을 가져오고, 생성하고, 삭제하는 역할도 서비스 계정에 필요합니다. 이러한 역할을 서비스 계정에 부여하지 않으려면 ``ImagePullSecrets``를 사전 생성하여 ContainerGroup의 Pod 사양에 지정할 수 있습니다. 이 경우 |ee|에는 연결된 컨테이너 레지스트리 인증 정보가 없어야 합니다. 그렇지 않으면 컨트롤러가 네임스페이스에 비밀을 생성하려고 합니다.

  • 서비스 계정과 연결된 토큰(OpenShift 또는 Kubernetes Bearer 토큰)

  • 클러스터와 연결된 CA 인증서

이 섹션에서는 |at|를 통해 컨테이너 그룹에서 작업을 실행하는 데 사용할 Openshift 클러스터(또는 K8s)에서 서비스 계정을 생성하는 방법을 설명합니다. 서비스 계정이 생성되면 해당 인증 정보가 Openshift 또는 Kubernetes API 전달자 토큰 인증 정보의 형태로 컨트롤러에 제공됩니다. 아래에서는 서비스 계정을 생성하고 |at| 구성에 필요한 정보를 수집하는 방법을 설명합니다.

컨트롤러를 구성하려면 다음을 수행합니다.

  1. 서비스 계정을 생성하려면 이 샘플 서비스 계정을 다운로드하여 사용할 수 있습니다. :다운로드:`containergroup sa <../../common/source/containergroup-sa.yml>` 는 위의 인증 정보를 얻기 위해 필요에 따라 수정할 수 있습니다.

  2. containergroup-sa.yml::의 구성을 적용합니다.

    oc apply -f containergroup-sa.yml
    
  3. 서비스 계정과 연결된 시크릿 이름을 가져옵니다.

    export SA_SECRET=$(oc get sa containergroup-service-account -o json | jq '.secrets[0].name' | tr -d '"')
    
  4. 시크릿에서 토큰을 가져옵니다.

    oc get secret $(echo ${SA_SECRET}) -o json | jq '.data.token' | xargs | base64 --decode > containergroup-sa.token
    
  5. CA 인증서를 가져옵니다.

    oc get secret $SA_SECRET -o json | jq '.data["ca.crt"]' | xargs | base64 --decode > containergroup-ca.crt
    
  6. containergroup-sa.tokencontainergroup-ca.crt 콘텐츠를 사용하여 컨테이너 그룹에 필요한 OpenShift 또는 Kubernetes API 전달자 토큰 에 대한 정보를 제공합니다.

컨테이너 그룹을 생성하려면 다음을 수행합니다.

  1. 컨트롤러 사용자 인터페이스를 사용하여 컨테이너 그룹과 함께 사용할 OpenShift 또는 Kubernetes API 전달자 토큰 인증 정보를 생성합니다. 자세한 내용은 |atu|에서 :ref:`ug_credentials_add`를 참조하십시오.

  2. 왼쪽 탐색 모음에서 **인스턴스 그룹**을 클릭해 인스턴스 그룹 구성 창으로 이동하여 새 컨테이너 그룹을 생성합니다.

  3. 추가 버튼을 클릭하고 **컨테이너 그룹 생성**을 선택합니다.

IG - create new CG

  1. 새 컨테이너 그룹의 이름을 입력하고 이전에 생성된 인증 정보를 선택하여 컨테이너 그룹에 연결합니다.

8.2.2. Pod 사양 사용자 지정

|aap|에서 간단한 기본 Pod 사양을 제공하지만 기본 Pod 사양을 덮어쓰는 사용자 지정 YAML(또는 JSON) 문서를 제공할 수 있습니다. 이 필드는 유효한 Pod JSON 또는 YAML로 《직렬화》할 수 있는 모든 사용자 지정 필드(즉, ImagePullSecrets)를 사용합니다. 전체 옵션 목록은 `OpenShift documentation <https://docs.openshift.com/online/pro/architecture/core_concepts/pods_and_services.html>`_에서 확인할 수 있습니다.

Pod 사양을 사용자 지정하려면 토글을 사용하여 Pod 사양 덮어쓰기 필드를 활성화하고 확장하여 Pod 사양 덮어쓰기 필드에 네임스페이스를 지정한 다음, 완료되면 **저장**을 클릭합니다.

IG - CG customize pod

필요한 경우 추가 사용자 지정을 제공할 수 있습니다. **확장**을 클릭하여 전체 사용자 지정 창을 봅니다.

_images/instance-group-customize-cg-pod-expanded.png

참고

작업 시작 시 사용되는 이미지는 작업과 연결된 |ee|에 따라 결정됩니다. 컨테이너 레지스트리 인증 정보가 |ee|과 연결되어 있는 경우 컨트롤러는 ``ImagePullSecret``을 생성하여 이미지를 가져오려고 합니다. 서비스 계정에 비밀 관리 권한을 부여하지 않으려면 ``ImagePullSecret``을 사전 생성하여 Pod 사양에 지정하고 사용되는 |ee|에서 모든 인증 정보를 생략해야 합니다.

이미지 가져오기 비밀을 생성하는 방법에 대한 자세한 내용은 `Red Hat Container Registry Authentication article <https://access.redhat.com/RegistryAuthentication>`_의 Pod에서 다른 보안 레지스트리의 이미지를 참조하도록 허용 섹션을 참조하십시오.

컨테이너 그룹이 성공적으로 생성되면 새로 생성된 컨테이너 그룹의 세부 정보 탭이 유지되므로 컨테이너 그룹 정보를 검토하고 편집할 수 있습니다. 인스턴스 그룹 링크에서 편집(edit-button) 버튼을 클릭했을 때 열리는 메뉴와 같습니다. **인스턴스**를 편집하고 이 인스턴스 그룹과 연결된 **작업**을 검토할 수도 있습니다.

IG - example CG successfully created

그에 따라 컨테이너 그룹과 인스턴스 그룹의 레이블이 지정됩니다.

참고

고객에게 사용자 지정 Pod 사양이 있지만 기본 ``pod_spec``이 변경되면 업그레이드가 어려울 수 있습니다. 대부분의 매니페스트는 아무 네임스페이스에나 적용할 수 있으며, 네임스페이스가 별도로 지정된 경우 대체로 네임스페이스를 덮어쓰기만 하면 됩니다. 마찬가지로, 여러 플랫폼 릴리스의 기본 이미지를 다양한 버전의 기본 작업 러너 컨테이너에 고정하는 것은 까다로운 작업입니다. 기본 이미지가 Pod 사양에 지정된 경우 업그레이드하더라도 기본 Pod 사양에 새롭게 적용된 기본 변경 사항이 선택되지 않습니다.

8.2.3. 컨테이너 그룹 기능 확인

컨테이너 배포 및 종료를 확인하려면 다음을 수행합니다.

  1. mock 인벤토리를 생성하고 인스턴스 그룹 필드에 컨테이너 그룹 이름을 채워 컨테이너 그룹을 인벤토리에 연결합니다. 자세한 내용은 |atu|에서 :ref:`ug_inventories_add`를 참조하십시오.

Dummy inventory

  1. 변수를 사용하여 인벤토리에 《localhost》 호스트를 생성합니다.

{'ansible_host': '127.0.0.1', 'ansible_connection': 'local'}

Inventory with localhost

  1. ping 또는 setup 모듈을 사용하여 localhost에 애드혹 작업을 시작합니다. 머신 인증 정보 필드는 필수지만 이 간단한 테스트에서는 어떤 것을 선택하든 상관없습니다.

Launch inventory with localhost

_images/inventories-launch-adhoc-cg-test-localhost2.png

작업 세부 정보 뷰에서는 애드혹 작업 하나를 사용하여 컨테이너에 성공적으로 도달한 것을 확인할 수 있습니다.

Inventory with localhost ping success

OpenShift UI가 있는 경우 Pod가 배포되고 종료될 때 표시되고 사라지는 것을 확인할 수 있습니다. 또는 CLI를 사용해 네임스페이스에서 get pod 작업을 수행하여 동일한 이벤트가 발생하는 것을 실시간으로 확인할 수 있습니다.

8.2.4. 컨테이너 그룹 작업 보기

컨테이너 그룹과 연결된 작업을 실행하는 경우 세부 정보 뷰와 이 뷰의 연결된 인스턴스 그룹 및 실행 노드에서 해당 작업의 세부 정보를 확인할 수 있습니다.

IG - instances jobs

8.2.5. Kubernetes API 실패 상태

컨테이너 그룹을 실행할 때 Kubernetes API가 리소스 할당량을 초과했다고 응답하는 경우 컨트롤러는 작업을 보류 상태로 유지합니다. 다른 실패가 발생하는 경우 다음 예제와 같이 실패 이유를 표시하는 오류 세부 정보 필드가 역추적됩니다.

_images/instance-group-cg-job-details-error.png

8.2.6. 컨테이너 용량 제한

컨테이너의 용량 제한 및 할당량은 Kubernetes API에서 오브젝트를 통해 정의됩니다.

참고

컨테이너 그룹은 일반 노드가 사용하는 용량 알고리즘을 사용하지 않습니다. 예를 들어 작업 템플릿 수준에서 포크 수를 명시적으로 설정해야 합니다. 포크가 컨트롤러에서 구성된 경우 해당 설정이 컨테이너로 전달됩니다.