CLI 참조

Windows용 CLI는 zip 아카이브로 제공됩니다. Red Hat 고객 포털에서 다운로드할 수 있습니다. Red Hat 계정으로 로그인한 후 다운로드 페이지에 액세스하려면 활성 OpenShift Enterprise 서브스크립션이 있어야 합니다.

Red Hat 고객 포털에서 CLI 다운로드

또는 클러스터 관리자가 이를 활성화한 경우 웹 콘솔의 정보 페이지에서 CLI를 다운로드하고 압축을 풀 수 있습니다.

튜토리얼 비디오:

다음 비디오에서는 이 프로세스를 안내합니다. 감시하려면 여기를 클릭하십시오.

그런 다음 ZIP 프로그램으로 아카이브의 압축을 풀고 oc 바이너리를 PATH의 디렉터리로 이동합니다. PATH를 확인하려면 명령 프롬프트를 열고 다음을 실행합니다.

C:\> path

Mac OS X용 CLI는 tar.gz 아카이브로 제공됩니다. Red Hat 고객 포털에서 다운로드할 수 있습니다. Red Hat 계정으로 로그인한 후 다운로드 페이지에 액세스하려면 활성 OpenShift Enterprise 서브스크립션이 있어야 합니다.

Red Hat 고객 포털에서 CLI 다운로드

또는 클러스터 관리자가 이를 활성화한 경우 웹 콘솔의 정보 페이지에서 CLI를 다운로드하고 압축을 풀 수 있습니다.

튜토리얼 비디오:

다음 비디오에서는 이 프로세스를 안내합니다. 감시하려면 여기를 클릭하십시오.

그런 다음 아카이브의 압축을 풀고 oc 바이너리를 PATH의 디렉터리로 이동합니다. PATH를 확인하려면 터미널 창을 열고 다음을 실행합니다.

$ echo $PATH

RHEL(Red Hat Enterprise Linux) 7의 경우 Red Hat 계정에 활성 OpenShift Enterprise 서브스크립션이 있는 경우 RHSM(Red Hat Subscription Management)을 사용하여 CLI를 RPM으로 설치할 수 있습니다.

RHEL, Fedora 및 기타 Linux 배포판의 경우 Red Hat 고객 포털에서 tar.gz 아카이브로 직접 CLI를 다운로드할 수도 있습니다. Red Hat 계정으로 로그인한 후 다운로드 페이지에 액세스하려면 활성 OpenShift Enterprise 서브스크립션이 있어야 합니다.

Red Hat 고객 포털에서 CLI 다운로드

튜토리얼 비디오:

다음 비디오에서는 이 프로세스를 안내합니다. 감시하려면 여기를 클릭하십시오.

또는 클러스터 관리자가 이를 활성화한 경우 웹 콘솔의 정보 페이지에서 CLI를 다운로드하고 압축을 풀 수 있습니다.

그런 다음 아카이브의 압축을 풀고 oc 바이너리를 PATH의 디렉터리로 이동합니다. 경로를 확인하려면 다음을 실행하십시오.

$ echo $PATH

아카이브의 압축을 풀려면 다음을 수행합니다.

$ tar -xf <file>

oc: No such file or directory

몇 가지 핵심 OpenShift Container Platform 개념에 대한 소개를 표시합니다.

$ oc types

OpenShift Container Platform 서버에 로그인합니다.

$ oc login

현재 세션을 종료합니다.

$ oc logout

새 프로젝트를 생성합니다.

$ oc new-project <project_name>

현재 디렉터리의 소스 코드를 기반으로 새 애플리케이션을 생성합니다.

$ oc new-app .

원격 리포지토리의 소스 코드를 기반으로 새 애플리케이션을 생성합니다.

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

프라이빗 원격 리포지토리에서 소스 코드를 기반으로 새 애플리케이션을 생성합니다.

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

현재 프로젝트의 개요를 표시합니다.

$ oc status

다른 프로젝트로 전환합니다. 옵션 없이 를 실행하여 현재 프로젝트를 표시합니다. 모든 프로젝트를 보려면 oc projects 를 실행할 수 있습니다.

$ oc project <project_name>

지정된 오브젝트 유형의 오브젝트 목록을 반환합니다. 선택 사항인 <object_name >이 요청에 포함된 경우 결과 목록은 해당 값에 의해 필터링됩니다.

$ oc get <object_type> [<object_name>]

예를 들어 다음 명령은 프로젝트에 사용 가능한 이미지를 나열합니다.

$ oc get images

sha256:f86e02fb8c740b4ed1f59300e94be69783ee51a38cc9ce6ddb73b6f817e173b3   registry.redhat.io/jboss-datagrid-6/datagrid65-openshift@sha256:f86e02fb8c740b4ed1f59300e94be69783ee51a38cc9ce6ddb73b6f817e173b3
sha256:f98f90938360ab1979f70195a9d518ae87b1089cd42ba5fc279d647b2cb0351b   registry.redhat.io/jboss-fuse-6/fis-karaf-openshift@sha256:f98f90938360ab1979f70195a9d518ae87b1089cd42ba5fc279d647b2cb0351b

-o 또는 --output 옵션을 사용하여 출력 형식을 수정할 수 있습니다.

$ oc get <object_type> [<object_name>]-o|--output=json|yaml|wide|custom-columns=...|custom-columns-file=...|go-template=...|go-template-file=...|jsonpath=...|jsonpath-file=...]

출력 형식은 JSON 또는 YAML 또는 사용자 지정 열,golang 템플릿, jsonpath 와 같은 확장 가능한 형식일 수 있습니다.

예를 들어 다음 명령은 특정 프로젝트에서 실행 중인 Pod의 이름을 나열합니다.

$ oc get pods -n default -o jsonpath='{range .items[*].metadata}{"Pod Name: "}{.name}{"\n"}{end}'

Pod Name: docker-registry-1-wvhrx
Pod Name: registry-console-1-ntq65
Pod Name: router-1-xzw69

쿼리에서 반환된 특정 오브젝트에 대한 정보를 반환합니다. 특정 &lt ;object_name&gt;을 제공해야 합니다. 사용 가능한 실제 정보는 오브젝트 유형에 설명된 대로 다릅니다.

$ oc describe <object_type> <object_name>

원하는 오브젝트 유형을 편집합니다.

$ oc edit <object_type>/<object_name>

지정된 텍스트 편집기를 사용하여 원하는 오브젝트 유형을 편집합니다.

$ OC_EDITOR="<text_editor>" oc edit <object_type>/<object_name>

지정된 형식으로 원하는 오브젝트를 편집합니다(예: JSON).

$ oc edit <object_type>/<object_name> \
    --output-version=<object_type_version> \
    -o <object_type_format>

볼륨 수정:

$ oc set volume <object_type>/<object_name> [--option]

오브젝트에서 레이블을 업데이트합니다.

$ oc label <object_type> <object_name> <label>

서비스를 조회하여 경로로 노출합니다. 또한 배포 구성, 복제 컨트롤러, 서비스 또는 Pod를 지정된 포트의 새 서비스로 노출하는 기능도 있습니다. 라벨이 지정되지 않은 경우 새 오브젝트는 표시하는 오브젝트에서 레이블을 다시 사용합니다.

서비스를 노출하는 경우 기본 생성기는 --generator=route/v1 입니다. 다른 모든 경우의 기본값은 --generator=service/v2 이며, 포트 이름이 지정되지 않은 상태로 유지됩니다. 일반적으로 oc expose 명령을 사용하여 생성기를 설정할 필요가 없습니다. 세 번째 생성기 --generator=service/v1 은 포트 이름 default와 함께 사용할 수 있습니다.

$ oc expose <object_type> <object_name>

지정된 오브젝트를 삭제합니다. 오브젝트 구성은 STDIN을 통해 전달할 수도 있습니다. oc delete all -l <label > 작업은 Pod가 다시 생성되지 않도록 복제 컨트롤러를 포함하여 지정된 < label >과 일치하는 모든 오브젝트를 삭제합니다.

$ oc delete -f <file_path>

$ oc delete <object_type> <object_name>

$ oc delete <object_type> -l <label>

$ oc delete all -l <label>

지정된 개체의 특정 속성을 수정합니다.

$ oc set env dc/mydc VAR1=value1

$ oc set build-secret --source bc/mybc mysecret

지정된 빌드 구성 파일을 사용하여 빌드 프로세스를 수동으로 시작합니다.

$ oc start-build <buildconfig_name>

이전 빌드의 이름을 시작점으로 지정하여 빌드 프로세스를 수동으로 시작합니다.

$ oc start-build --from-build=<build_name>

구성 파일 또는 이전 빌드의 이름을 지정하여 빌드 프로세스를 수동으로 시작하고 해당 빌드 로그를 검색합니다.

$ oc start-build --from-build=<build_name> --follow

$ oc start-build <buildconfig_name> --follow

빌드가 실패하면 빌드가 완료되고 0이 아닌 반환 코드로 종료될 때까지 기다립니다.

$ oc start-build --from-build=<build_name> --wait

빌드 구성을 변경하지 않고 현재 빌드의 환경 변수를 설정하거나 재정의합니다. 또는 -e 를 사용합니다.

$ oc start-build --env <var_name>=<value>

빌드 중 기본 빌드 로그 수준 출력을 설정하거나 덮어씁니다.

$ oc start-build --build-loglevel [0-5]

빌드에서 사용해야 하는 소스 코드 커밋 식별자를 지정합니다. Git 리포지토리에 따라 빌드가 필요합니다.

$ oc start-build --commit=<hash>

< build_name>을 사용하여 빌드를 다시 실행합니다.

$ oc start-build --from-build=<build_name>

& lt;dir_name >을 보관하고 바이너리 입력으로 빌드합니다.

$ oc start-build --from-dir=<dir_name>

기존 아카이브를 바이너리 입력으로 사용합니다. --from-file 과 달리 빌드 프로세스 전에 빌더에서 아카이브를 추출합니다.

$ oc start-build --from-archive=<archive_name>

& lt;file_name& gt;을 빌드의 바이너리 입력으로 사용합니다. 이 파일은 빌드 소스에서 유일한 파일이어야 합니다. 예: pom.xml 또는 Dockerfile.

$ oc start-build --from-file=<file_name>

파일 시스템에서 HTTP 또는 HTTPS를 읽는 대신 HTTP 또는 HTTPS를 사용하여 바이너리 입력을 다운로드합니다.

$ oc start-build --from-file=<file_URL>

아카이브를 다운로드하고 해당 콘텐츠를 빌드 소스로 사용합니다.

$ oc start-build --from-archive=<archive_URL>

빌드에 바이너리 입력으로 사용할 로컬 소스 코드 리포지토리의 경로입니다.

$ oc start-build --from-repo=<path_to_repo>

트리거할 기존 빌드 구성의 Webhook URL을 지정합니다.

$ oc start-build --from-webhook=<webhook_URL>

빌드를 트리거하기 위한 사후 후크의 내용입니다.

$ oc start-build --git-post-receive=<contents>

post-receive의 Git 리포지토리 경로입니다. 기본값은 현재 디렉터리입니다.

$ oc start-build --git-repository=<path_to_repo>

지정된 빌드 구성 또는 빌드에 대한 Webhook를 나열합니다. 모든,일반 또는 github 를 허용합니다.

$ oc start-build --list-webhooks

source-strategy 빌드의 Spec.Strategy.SourceStrategy.Incremental 옵션을 재정의합니다.

$ oc start-build --incremental

docker-strategy 빌드의 Spec.Strategy.DockerStrategy.NoCache 옵션을 재정의합니다.

$oc start-build --no-cache

롤백 을 수행합니다.

$ oc rollback <deployment_name>

현재 Git 리포지토리(공용 원격 사용) 및 컨테이너 이미지의 소스 코드를 기반으로 빌드 구성을 생성합니다.

$ oc new-build .

원격 git 리포지터리를 기반으로 빌드 구성을 생성합니다.

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

개인 원격 git 리포지터리를 기반으로 빌드 구성을 생성합니다.

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

진행 중인 빌드를 중지합니다.

$ oc cancel-build <build_name>

동시에 여러 빌드를 취소합니다.

$ oc cancel-build <build1_name> <build2_name> <build3_name>

빌드 구성에서 생성된 모든 빌드를 취소합니다.

$ oc cancel-build bc/<buildconfig_name>

취소할 빌드를 지정합니다.

$ oc cancel-build bc/<buildconfig_name> --state=<state>

상태에 대한 예제 값은 새 또는 보류 중입니다.

외부 이미지 리포지토리에서 태그 및 이미지 정보를 가져옵니다.

$ oc import-image <image_stream>

복제 컨트롤러 또는 배포 구성에 대해 원하는 복제본 수를 지정된 복제본 수로 설정합니다.

$ oc scale <object_type> <object_name> --replicas=<#_of_replicas>

이미지 스트림에서 기존 태그 또는 이미지 또는 컨테이너 이미지 "pull spec"을 가져와서 하나 이상의 다른 이미지 스트림에서 태그의 최신 이미지로 설정합니다.

$ oc tag <current_image> <image_stream>

구성 파일을 구문 분석하고 파일 콘텐츠를 기반으로 하나 이상의 OpenShift Container Platform 오브젝트를 생성합니다. -f 플래그는 다른 파일 또는 디렉터리 경로로 여러 번 전달할 수 있습니다. 플래그가 여러 번 전달되면 oc create 는 각 파일을 반복하여 표시된 모든 파일에 설명된 오브젝트를 생성합니다. 기존 리소스는 모두 무시됩니다.

$ oc create -f <file_or_dir_path>

지정된 구성 파일의 콘텐츠를 기반으로 기존 오브젝트를 수정하려고 합니다. -f 플래그는 다른 파일 또는 디렉터리 경로로 여러 번 전달할 수 있습니다. 플래그가 여러 번 전달되면 oc replace 가 각 파일을 반복하여 표시된 모든 파일에 설명된 오브젝트를 업데이트합니다.

$ oc replace -f <file_or_dir_path>

프로젝트 템플릿을 프로젝트 구성 파일로 변환합니다.

$ oc process -f <template_file_path>

특정 이미지를 만들고 실행할 수 있으며, 복제될 수 있습니다. 기본적으로 생성된 컨테이너를 관리할 배포 구성을 생성합니다. --generator 플래그를 사용하여 다른 리소스를 생성하도록 선택할 수 있습니다.

대화형 컨테이너 실행을 위해 foreground에서 실행하도록 선택할 수 있습니다.

$ oc run NAME --image=<image> \
    [--generator=<resource>] \
    [--port=<port>] \
    [--replicas=<replicas>] \
    [--dry-run=<bool>] \
    [--overrides=<inline_json>] \
    [options]

전략적 병합 패치를 사용하여 오브젝트 필드를 하나 이상 업데이트합니다.

$ oc patch <object_type> <object_name> -p <changes>

<changes>는 새 필드와 값이 포함된 JSON 또는 YAML 표현식입니다. 예를 들어 노드 node1 의 spec.unschedulable 필드를 true 값으로 업데이트하려면 json 표현식은 다음과 같습니다.

$ oc patch node node1 -p '{"spec":{"unschedulable":true}}'

권한 부여 정책을 관리합니다.

$ oc policy [--options]

보안 구성:

$ oc secrets [--options] path/to/ssh_key

애플리케이션 자동 스케일러 를 설정합니다. 클러스터에서 지표를 활성화해야 합니다. 필요한 경우 클러스터 관리자 지침은 Enabling Cluster Metrics for cluster administrator instructions를 참조하십시오.

$ oc autoscale dc/<dc_name> [--options]

실행 중인 애플리케이션을 디버깅하는 명령 쉘을 시작합니다.

$ oc debug -h

이미지 및 설정 문제를 디버깅할 때 실행 중인 Pod 구성의 정확한 사본을 가져오고 쉘을 사용하여 문제를 해결할 수 있습니다. 실패한 Pod가 시작되지 않고 rsh 또는 exec 에 액세스할 수 없으므로 debug 명령을 실행하면 해당 설정의 이산적 사본이 생성됩니다.

기본 모드는 참조된 Pod, 복제 컨트롤러 또는 배포 구성의 첫 번째 컨테이너 내에서 쉘을 시작하는 것입니다. 시작된 Pod는 라벨이 제거하고 명령이 /bin/sh 로 변경되었으며 준비 및 활성 상태 점검이 비활성화된 소스 포드의 사본입니다. 명령을 실행하려는 경우 -- 및 명령을 추가하여 실행합니다. 명령을 전달해도 TTY가 생성되지 않거나 기본적으로 STDIN을 보내지 않습니다. 일반적인 방식으로 컨테이너 또는 Pod를 변경하는 데 다른 플래그가 지원됩니다.

컨테이너를 실행하는 일반적인 문제는 클러스터에서 root 사용자로 실행하지 못하도록 하는 보안 정책입니다. 이 명령을 사용하여 Pod를 루트가 아닌(- as-user)로 실행하거나 루트가 아닌 Pod를 root로 실행(- as-root)으로 실행할 수 있습니다.

원격 명령이 완료되거나 쉘을 중단할 때 디버그 Pod가 삭제됩니다.

$ oc debug RESOURCE/NAME [ENV1=VAL1 ...] [-c CONTAINER] [options] [-- COMMAND]

$ oc debug dc/test

$ oc debug dc/test --as-user=1000000

$ oc debug dc/test -c second -- /bin/env

$ oc debug dc/test -o yaml

특정 빌드, 배포 또는 Pod의 로그 출력을 검색합니다. 이 명령은 빌드, 빌드 구성, 배포 구성 및 Pod에 대해 작동합니다.

$ oc logs -f <pod> -c <container_name>

이미 실행 중인 컨테이너에서 명령을 실행합니다. 선택적으로 컨테이너 ID를 지정할 수 있습니다. 그렇지 않으면 기본값은 첫 번째 컨테이너로 설정됩니다.

$ oc exec <pod> [-c <container>] <command>

컨테이너에 대한 원격 쉘 세션을 엽니다.

$ oc rsh <pod>

이미 실행 중인 Pod 컨테이너의 디렉터리 또는 디렉터리의 콘텐츠를 복사합니다. 컨테이너를 지정하지 않으면 기본적으로 Pod의 첫 번째 컨테이너로 설정됩니다.

로컬 디렉터리에서 Pod의 디렉터리로 콘텐츠를 복사하려면 다음을 수행합니다.

$ oc rsync <local_dir> <pod>:<pod_dir> -c <container>

Pod의 디렉터리에서 로컬 디렉터리로 콘텐츠를 복사하려면 다음을 수행합니다.

$ oc rsync <pod>:<pod_dir> <local_dir> -c <container>

Pod에 하나 이상의 로컬 포트를 전달합니다.

$ oc port-forward <pod> <local_port>:<remote_port>

Kubernetes API 서버에 대해 프록시를 실행합니다.

$ oc proxy --port=<port> --www=<static_directory>

새 프로젝트를 생성합니다.

$ oc adm new-project <project_name>

권한 부여 정책을 관리합니다.

$ oc adm policy

그룹을 관리합니다.

$ oc adm groups

라우터를 설치합니다.

$ oc adm router <router_name>

노드 집합에 대한 IP 페일오버 그룹을 설치합니다.

$ oc adm ipfailover <ipfailover_config>

통합 컨테이너 이미지 레지스트리를 설치합니다.

$ oc adm registry

빌드의 입력 및 종속 항목을 출력합니다.

$ oc adm build-chain <image_stream>[:<tag>]

노드를 관리합니다. 예를 들어 Pod를 나열하거나 비우거나 준비 상태로 표시합니다.

$ oc adm manage-node

서버에서 이전 버전의 리소스를 제거합니다.

$ oc adm prune

kubelet 구성 파일을 변경합니다.

$ oc adm config <subcommand>

클라이언트 인증서에서 기본 .kubeconfig 파일을 생성합니다.

$ oc adm create-kubeconfig

서버에 사용자로 연결하기 위한 구성 파일을 생성합니다.

$ oc adm create-api-client-config

부트스트랩 프로젝트 템플릿을 생성합니다.

$ oc adm create-bootstrap-project-template

기본 부트스트랩 정책을 생성합니다.

$ oc adm create-bootstrap-policy-file

로그인 템플릿을 생성합니다.

$ oc adm create-login-template

노드에 대한 구성 번들을 생성합니다.

$ oc adm create-node-config

인증서 및 키를 관리합니다.

$ oc adm ca

플러그인 로더는 플러그인 파일을 검색하고 플러그인이 실행하는 데 필요한 최소한의 정보를 제공하는지 확인합니다. 최소 정보를 제공하지 않는 올바른 위치에 배치된 파일은 (예: 불완전한 plugin.yaml 설명자) 무시됩니다.

설명자 파일은 다음 속성을 지원합니다.

name: "great-plugin"              # REQUIRED: the plug-in command name, to be invoked under 'kubectl'
shortDesc: "great-plugin plug-in" # REQUIRED: the command short description, for help
longDesc: ""                      # the command long description, for help
example: ""                       # command example(s), for help
command: "./example"              # REQUIRED: the command, binary, or script to invoke when running the plug-in
flags:                            # flags supported by the plug-in
  - name: "flag-name"             # REQUIRED for each flag: flag name
    shorthand: "f"                # short version of the flag name
    desc: "example flag"          # REQUIRED for each flag: flag description
    defValue: "extreme"           # default value of the flag
tree:                             # allows the declaration of subcommands
  - ...                           # subcommands support the same set of attributes

앞의 설명자는 -f | --flag-name 이라는 하나의 플래그가 있는 great-plugin 플러그인을 선언합니다. 다음과 같이 호출할 수 있습니다.

$ oc plugin great-plugin -f value

플러그인이 호출되면 설명자 파일과 동일한 디렉터리에 있는 예제 바이너리 또는 스크립트를 호출하여 여러 인수 및 환경 변수를 전달합니다. 액세스 런타임 속성 섹션에서는 example 명령이 플래그 값과 기타 런타임 컨텍스트에 액세스하는 방법을 설명합니다.

각 플러그인에는 파일 시스템에 자체 하위 디렉터리가 있으며, 바람직하게는 플러그인 명령과 동일한 이름을 사용하는 것이 좋습니다. 디렉터리에는 plugin.yaml 설명자와 필요한 바이너리, 스크립트, 자산 또는 기타 종속성이 포함되어야 합니다.

예를 들어 great-plugin 플러그인의 디렉터리 구조는 다음과 같습니다.

~/.kube/plugins/
└── great-plugin
    ├── plugin.yaml
    └── example

대부분의 사용 사례에서 플러그인을 지원하도록 작성한 바이너리 또는 스크립트 파일은 플러그인 프레임워크에서 제공하는 일부 컨텍스트 정보에 액세스할 수 있어야 합니다. 예를 들어 설명자 파일에서 플래그를 선언한 경우 플러그인은 런타임 시 사용자 제공 플래그 값에 액세스할 수 있어야 합니다.

이는 global flags에서도 마찬가지입니다. 플러그인 프레임워크는 이를 수행해야 하므로 플러그인 작성자는 인수 구문 분석에 대해 걱정할 필요가 없습니다. 또한 플러그인과 일반 oc 명령 간의 일관성을 극대화합니다.

플러그인은 환경 변수를 통해 런타임 컨텍스트 속성에 액세스할 수 있습니다. 예를 들어 플래그를 통해 제공되는 값에 액세스하려면 바이너리 또는 스크립트에 대한 적절한 함수 호출을 사용하여 적절한 환경 변수의 값을 찾습니다.

지원되는 환경 변수는 다음과 같습니다.