이 섹션의 다중 페이지 출력 화면임. 여기를 클릭하여 프린트.
kubectl
- 1: kubectl 개요
- 2: JSONPath 지원
- 3: kubectl
- 4: kubectl 사용 규칙
- 5: kubectl 치트 시트
- 6: 도커 사용자를 위한 kubectl
1 - kubectl 개요
Kubectl은 쿠버네티스 클러스터를 제어하기 위한 커맨드 라인 도구이다.
구성을 위해, kubectl
은 config 파일을 $HOME/.kube 에서 찾는다.
KUBECONFIG 환경 변수를 설정하거나 --kubeconfig
플래그를 설정하여 다른 kubeconfig
파일을 지정할 수 있다.
이 개요는 kubectl
구문을 다루고, 커맨드 동작을 설명하며, 일반적인 예제를 제공한다.
지원되는 모든 플래그 및 하위 명령을 포함한 각 명령에 대한 자세한 내용은
kubectl 참조 문서를 참고한다.
설치 방법에 대해서는 kubectl 설치를 참고한다.
구문
터미널 창에서 kubectl
명령을 실행하려면 다음의 구문을 사용한다.
kubectl [command] [TYPE] [NAME] [flags]
다음은 command
, TYPE
, NAME
과 flags
에 대한 설명이다.
-
command
: 하나 이상의 리소스에서 수행하려는 동작을 지정한다. 예:create
,get
,describe
,delete
-
TYPE
: 리소스 타입을 지정한다. 리소스 타입은 대소문자를 구분하지 않으며 단수형, 복수형 또는 약어 형식을 지정할 수 있다. 예를 들어, 다음의 명령은 동일한 출력 결과를 생성한다.kubectl get pod pod1 kubectl get pods pod1 kubectl get po pod1
-
NAME
: 리소스 이름을 지정한다. 이름은 대소문자를 구분한다. 이름을 생략하면, 모든 리소스에 대한 세부 사항이 표시된다. 예:kubectl get pods
여러 리소스에 대한 작업을 수행할 때, 타입 및 이름별로 각 리소스를 지정하거나 하나 이상의 파일을 지정할 수 있다.
-
타입 및 이름으로 리소스를 지정하려면 다음을 참고한다.
-
리소스가 모두 동일한 타입인 경우 리소스를 그룹화하려면 다음을 사용한다.
TYPE1 name1 name2 name<#>
예:kubectl get pod example-pod1 example-pod2
-
여러 리소스 타입을 개별적으로 지정하려면 다음을 사용한다.
TYPE1/name1 TYPE1/name2 TYPE2/name3 TYPE<#>/name<#>
예:kubectl get pod/example-pod1 replicationcontroller/example-rc1
-
-
하나 이상의 파일로 리소스를 지정하려면 다음을 사용한다.
-f file1 -f file2 -f file<#>
- YAML이 특히 구성 파일에 대해 더 사용자 친화적이므로, JSON 대신 YAML을 사용한다.
예:kubectl get -f ./pod.yaml
- YAML이 특히 구성 파일에 대해 더 사용자 친화적이므로, JSON 대신 YAML을 사용한다.
-
-
flags
: 선택적 플래그를 지정한다. 예를 들어,-s
또는--server
플래그를 사용하여 쿠버네티스 API 서버의 주소와 포트를 지정할 수 있다.
도움이 필요하다면, 터미널 창에서 kubectl help
를 실행한다.
클러스터 내 인증과 네임스페이스 오버라이드
기본적으로 kubectl
은 먼저 자신이 파드 안에서 실행되고 있는지, 즉 클러스터 안에 있는지를 판별한다. 이를 위해 KUBERNETES_SERVICE_HOST
와 KUBERNETES_SERVICE_PORT
환경 변수, 그리고 서비스 어카운트 토큰 파일이 /var/run/secrets/kubernetes.io/serviceaccount/token
경로에 있는지를 확인한다. 세 가지가 모두 감지되면, 클러스터 내 인증이 적용된다.
하위 호환성을 위해, 클러스터 내 인증 시에 POD_NAMESPACE
환경 변수가 설정되어 있으면, 서비스 어카운트 토큰의 기본 네임스페이스 설정을 오버라이드한다. 기본 네임스페이스 설정에 의존하는 모든 매니페스트와 도구가 영향을 받을 것이다.
POD_NAMESPACE
환경 변수
POD_NAMESPACE
환경 변수가 설정되어 있으면, 네임스페이스에 속하는 자원에 대한 CLI 작업은 환경 변수에 설정된 네임스페이스를 기본값으로 사용한다. 예를 들어, 환경 변수가 seattle
로 설정되어 있으면, kubectl get pods
명령은 seattle
네임스페이스에 있는 파드 목록을 반환한다. 이는 파드가 네임스페이스에 속하는 자원이며, 명령어에 네임스페이스를 특정하지 않았기 때문이다. kubectl api-resources
명령을 실행하고 결과를 확인하여 특정 자원이 네임스페이스에 속하는 자원인지 판별한다.
명시적으로 --namespace <value>
인자를 사용하면 위와 같은 동작을 오버라이드한다.
kubectl이 서비스어카운트 토큰을 관리하는 방법
만약
- 쿠버네티스 서비스 어카운트 토큰 파일이
/var/run/secrets/kubernetes.io/serviceaccount/token
경로에 마운트되어 있고, KUBERNETES_SERVICE_HOST
환경 변수가 설정되어 있고,KUBERNETES_SERVICE_PORT
환경 변수가 설정되어 있고,- kubectl 명령에 네임스페이스를 명시하지 않으면
kubectl은 자신이 클러스터 내부에서 실행되고 있다고 가정한다.
kubectl은 해당 서비스어카운트의 네임스페이스(파드의 네임스페이스와 동일하다)를 인식하고 해당 네임스페이스에 대해 동작한다.
이는 클러스터 외부에서 실행되었을 때와는 다른데,
kubectl이 클러스터 외부에서 실행되었으며 네임스페이스가 명시되지 않은 경우
kubectl은 default
네임스페이스에 대해 동작한다.
명령어
다음 표에는 모든 kubectl
작업에 대한 간단한 설명과 일반적인 구문이 포함되어 있다.
명령어 | 구문 | 설명 |
---|---|---|
alpha |
kubectl alpha SUBCOMMAND [flags] |
쿠버네티스 클러스터에서 기본적으로 활성화되어 있지 않은 알파 기능의 사용할 수 있는 명령을 나열한다. |
annotate |
kubectl annotate (-f FILENAME | TYPE NAME | TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags] |
하나 이상의 리소스 어노테이션을 추가하거나 업데이트한다. |
api-resources |
kubectl api-resources [flags] |
사용 가능한 API 리소스를 나열한다. |
api-versions |
kubectl api-versions [flags] |
사용 가능한 API 버전을 나열한다. |
apply |
kubectl apply -f FILENAME [flags] |
파일이나 표준입력(stdin)으로부터 리소스에 구성 변경 사항을 적용한다. |
attach |
kubectl attach POD -c CONTAINER [-i] [-t] [flags] |
실행 중인 컨테이너에 연결하여 출력 스트림을 보거나 표준입력을 통해 컨테이너와 상호 작용한다. |
auth |
kubectl auth [flags] [options] |
승인을 검사한다. |
autoscale |
kubectl autoscale (-f FILENAME | TYPE NAME | TYPE/NAME) [--min=MINPODS] --max=MAXPODS [--cpu-percent=CPU] [flags] |
레플리케이션 컨트롤러에서 관리하는 파드 집합을 자동으로 조정한다. |
certificate |
kubectl certificate SUBCOMMAND [options] |
인증서 리소스를 수정한다. |
cluster-info |
kubectl cluster-info [flags] |
클러스터의 마스터와 서비스에 대한 엔드포인트 정보를 표시한다. |
completion |
kubectl completion SHELL [options] |
지정된 셸(bash 또는 zsh)에 대한 셸 완성 코드를 출력한다. |
config |
kubectl config SUBCOMMAND [flags] |
kubeconfig 파일을 수정한다. 세부 사항은 개별 하위 명령을 참고한다. |
convert |
kubectl convert -f FILENAME [options] |
다른 API 버전 간에 구성 파일을 변환한다. YAML 및 JSON 형식이 모두 허용된다. 참고 - kubectl-convert 플러그인을 설치해야 한다. |
cordon |
kubectl cordon NODE [options] |
노드를 스케줄 불가능(unschedulable)으로 표시한다. |
cp |
kubectl cp <file-spec-src> <file-spec-dest> [options] |
컨테이너에서 그리고 컨테이너로 파일 및 디렉터리를 복사한다. |
create |
kubectl create -f FILENAME [flags] |
파일이나 표준입력에서 하나 이상의 리소스를 생성한다. |
delete |
kubectl delete (-f FILENAME | TYPE [NAME | /NAME | -l label | --all]) [flags] |
파일, 표준입력 또는 레이블 셀렉터, 이름, 리소스 셀렉터 또는 리소스를 지정하여 리소스를 삭제한다. |
describe |
kubectl describe (-f FILENAME | TYPE [NAME_PREFIX | /NAME | -l label]) [flags] |
하나 이상의 리소스의 자세한 상태를 표시한다. |
diff |
kubectl diff -f FILENAME [flags] |
라이브 구성에 대해 파일이나 표준입력의 차이점을 출력한다. |
drain |
kubectl drain NODE [options] |
유지 보수를 준비 중인 노드를 드레인한다. |
edit |
kubectl edit (-f FILENAME | TYPE NAME | TYPE/NAME) [flags] |
기본 편집기를 사용하여 서버에서 하나 이상의 리소스 정의를 편집하고 업데이트한다. |
exec |
kubectl exec POD [-c CONTAINER] [-i] [-t] [flags] [-- COMMAND [args...]] |
파드의 컨테이너에 대해 명령을 실행한다. |
explain |
kubectl explain [--recursive=false] [flags] |
파드, 노드, 서비스 등의 다양한 리소스에 대한 문서를 출력한다. |
expose |
kubectl expose (-f FILENAME | TYPE NAME | TYPE/NAME) [--port=port] [--protocol=TCP|UDP] [--target-port=number-or-name] [--name=name] [--external-ip=external-ip-of-service] [--type=type] [flags] |
레플리케이션 컨트롤러, 서비스 또는 파드를 새로운 쿠버네티스 서비스로 노출한다. |
get |
kubectl get (-f FILENAME | TYPE [NAME | /NAME | -l label]) [--watch] [--sort-by=FIELD] [[-o | --output]=OUTPUT_FORMAT] [flags] |
하나 이상의 리소스를 나열한다. |
kustomize |
kubectl kustomize <dir> [flags] [options] |
kustomization.yaml 파일의 지시 사항에서 생성된 API 리소스 집합을 나열한다. 인수는 파일을 포함하는 디렉터리의 경로이거나, 리포지터리 루트와 관련하여 경로 접미사가 동일한 git 리포지터리 URL이어야 한다. |
label |
kubectl label (-f FILENAME | TYPE NAME | TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags] |
하나 이상의 리소스 레이블을 추가하거나 업데이트한다. |
logs |
kubectl logs POD [-c CONTAINER] [--follow] [flags] |
파드의 컨테이너에 대한 로그를 출력한다. |
options |
kubectl options |
모든 명령에 적용되는 전역 커맨드 라인 옵션을 나열한다. |
patch |
kubectl patch (-f FILENAME | TYPE NAME | TYPE/NAME) --patch PATCH [flags] |
전략적 병합 패치 프로세스를 사용하여 리소스의 하나 이상의 필드를 업데이트한다. |
plugin |
kubectl plugin [flags] [options] |
플러그인과 상호 작용하기 위한 유틸리티를 제공한다. |
port-forward |
kubectl port-forward POD [LOCAL_PORT:]REMOTE_PORT [...[LOCAL_PORT_N:]REMOTE_PORT_N] [flags] |
하나 이상의 로컬 포트를 파드로 전달한다. |
proxy |
kubectl proxy [--port=PORT] [--www=static-dir] [--www-prefix=prefix] [--api-prefix=prefix] [flags] |
쿠버네티스 API 서버에 프록시를 실행한다. |
replace |
kubectl replace -f FILENAME |
파일 또는 표준입력에서 리소스를 교체한다. |
rollout |
kubectl rollout SUBCOMMAND [options] |
리소스의 롤아웃을 관리한다. 유효한 리소스 타입에는 디플로이먼트(deployment), 데몬셋(daemonset)과 스테이트풀셋(statefulset)이 포함된다. |
run |
kubectl run NAME --image=image [--env="key=value"] [--port=port] [--dry-run=server|client|none] [--overrides=inline-json] [flags] |
클러스터에서 지정된 이미지를 실행한다. |
scale |
kubectl scale (-f FILENAME | TYPE NAME | TYPE/NAME) --replicas=COUNT [--resource-version=version] [--current-replicas=count] [flags] |
지정된 레플리케이션 컨트롤러의 크기를 업데이트한다. |
set |
kubectl set SUBCOMMAND [options] |
애플리케이션 리소스를 구성한다. |
taint |
kubectl taint NODE NAME KEY_1=VAL_1:TAINT_EFFECT_1 ... KEY_N=VAL_N:TAINT_EFFECT_N [options] |
하나 이상의 노드에서 테인트(taint)를 업데이트한다. |
top |
kubectl top [flags] [options] |
리소스(CPU/메모리/스토리지) 사용량을 표시한다. |
uncordon |
kubectl uncordon NODE [options] |
노드를 스케줄 가능(schedulable)으로 표시한다. |
version |
kubectl version [--client] [flags] |
클라이언트와 서버에서 실행 중인 쿠버네티스 버전을 표시한다. |
wait |
kubectl wait ([-f FILENAME] | resource.group/resource.name | resource.group [(-l label | --all)]) [--for=delete|--for condition=available] [options] |
실험(experimental) 기능: 하나 이상의 리소스에서 특정 조건을 기다린다. |
명령 동작에 대한 자세한 내용을 배우려면 kubectl 참조 문서를 참고한다.
리소스 타입
다음 표에는 지원되는 모든 리소스 타입과 해당 약어가 나열되어 있다.
(이 출력은 kubectl api-resources
에서 확인할 수 있으며, 쿠버네티스 1.19.1 에서의 출력을 기준으로 한다.)
NAME | SHORTNAMES | APIGROUP | NAMESPACED | KIND |
---|---|---|---|---|
bindings |
true | Binding | ||
componentstatuses |
cs |
false | ComponentStatus | |
configmaps |
cm |
true | ConfigMap | |
endpoints |
ep |
true | Endpoints | |
events |
ev |
true | Event | |
limitranges |
limits |
true | LimitRange | |
namespaces |
ns |
false | Namespace | |
nodes |
no |
false | Node | |
persistentvolumeclaims |
pvc |
true | PersistentVolumeClaim | |
persistentvolumes |
pv |
false | PersistentVolume | |
pods |
po |
true | Pod | |
podtemplates |
true | PodTemplate | ||
replicationcontrollers |
rc |
true | ReplicationController | |
resourcequotas |
quota |
true | ResourceQuota | |
secrets |
true | Secret | ||
serviceaccounts |
sa |
true | ServiceAccount | |
services |
svc |
true | Service | |
mutatingwebhookconfigurations |
admissionregistration.k8s.io | false | MutatingWebhookConfiguration | |
validatingwebhookconfigurations |
admissionregistration.k8s.io | false | ValidatingWebhookConfiguration | |
customresourcedefinitions |
crd,crds |
apiextensions.k8s.io | false | CustomResourceDefinition |
apiservices |
apiregistration.k8s.io | false | APIService | |
controllerrevisions |
apps | true | ControllerRevision | |
daemonsets |
ds |
apps | true | DaemonSet |
deployments |
deploy |
apps | true | Deployment |
replicasets |
rs |
apps | true | ReplicaSet |
statefulsets |
sts |
apps | true | StatefulSet |
tokenreviews |
authentication.k8s.io | false | TokenReview | |
localsubjectaccessreviews |
authorization.k8s.io | true | LocalSubjectAccessReview | |
selfsubjectaccessreviews |
authorization.k8s.io | false | SelfSubjectAccessReview | |
selfsubjectrulesreviews |
authorization.k8s.io | false | SelfSubjectRulesReview | |
subjectaccessreviews |
authorization.k8s.io | false | SubjectAccessReview | |
horizontalpodautoscalers |
hpa |
autoscaling | true | HorizontalPodAutoscaler |
cronjobs |
cj |
batch | true | CronJob |
jobs |
batch | true | Job | |
certificatesigningrequests |
csr |
certificates.k8s.io | false | CertificateSigningRequest |
leases |
coordination.k8s.io | true | Lease | |
endpointslices |
discovery.k8s.io | true | EndpointSlice | |
events |
ev |
events.k8s.io | true | Event |
ingresses |
ing |
extensions | true | Ingress |
flowschemas |
flowcontrol.apiserver.k8s.io | false | FlowSchema | |
prioritylevelconfigurations |
flowcontrol.apiserver.k8s.io | false | PriorityLevelConfiguration | |
ingressclasses |
networking.k8s.io | false | IngressClass | |
ingresses |
ing |
networking.k8s.io | true | Ingress |
networkpolicies |
netpol |
networking.k8s.io | true | NetworkPolicy |
runtimeclasses |
node.k8s.io | false | RuntimeClass | |
poddisruptionbudgets |
pdb |
policy | true | PodDisruptionBudget |
podsecuritypolicies |
psp |
policy | false | PodSecurityPolicy |
clusterrolebindings |
rbac.authorization.k8s.io | false | ClusterRoleBinding | |
clusterroles |
rbac.authorization.k8s.io | false | ClusterRole | |
rolebindings |
rbac.authorization.k8s.io | true | RoleBinding | |
roles |
rbac.authorization.k8s.io | true | Role | |
priorityclasses |
pc |
scheduling.k8s.io | false | PriorityClass |
csidrivers |
storage.k8s.io | false | CSIDriver | |
csinodes |
storage.k8s.io | false | CSINode | |
storageclasses |
sc |
storage.k8s.io | false | StorageClass |
volumeattachments |
storage.k8s.io | false | VolumeAttachment |
출력 옵션
특정 명령의 출력을 서식화하거나 정렬하는 방법에 대한 정보는 다음 섹션을 참고한다. 다양한 출력 옵션을 지원하는 명령에 대한 자세한 내용은 kubectl 참조 문서를 참고한다.
출력 서식화
모든 kubectl
명령의 기본 출력 형식은 사람이 읽을 수 있는 일반 텍스트 형식이다. 특정 형식으로 터미널 창에 세부 정보를 출력하려면, 지원되는 kubectl
명령에 -o
또는 --output
플래그를 추가할 수 있다.
구문
kubectl [command] [TYPE] [NAME] -o <output_format>
kubectl
명령에 따라, 다음과 같은 출력 형식이 지원된다.
출력 형식 | 설명 |
---|---|
-o custom-columns=<spec> |
쉼표로 구분된 사용자 정의 열 목록을 사용하여 테이블을 출력한다. |
-o custom-columns-file=<filename> |
<filename> 파일에서 사용자 정의 열 템플릿을 사용하여 테이블을 출력한다. |
-o json |
JSON 형식의 API 오브젝트를 출력한다. |
-o jsonpath=<template> |
jsonpath 표현식에 정의된 필드를 출력한다. |
-o jsonpath-file=<filename> |
<filename> 파일에서 jsonpath 표현식으로 정의된 필드를 출력한다. |
-o name |
리소스 이름만 출력한다. |
-o wide |
추가 정보가 포함된 일반 텍스트 형식으로 출력된다. 파드의 경우, 노드 이름이 포함된다. |
-o yaml |
YAML 형식의 API 오브젝트를 출력한다. |
예제
이 예제에서, 다음의 명령은 단일 파드에 대한 세부 정보를 YAML 형식의 오브젝트로 출력한다.
kubectl get pod web-pod-13je7 -o yaml
기억하기: 각 명령이 지원하는 출력 형식에 대한 자세한 내용은 kubectl 참조 문서를 참고한다.
사용자 정의 열
사용자 정의 열을 정의하고 원하는 세부 정보만 테이블에 출력하려면, custom-columns
옵션을 사용할 수 있다.
사용자 정의 열을 인라인으로 정의하거나 템플릿 파일을 사용하도록 선택할 수 있다. -o custom-columns=<spec>
또는 -o custom-columns-file=<filename>
예제
인라인:
kubectl get pods <pod-name> -o custom-columns=NAME:.metadata.name,RSRC:.metadata.resourceVersion
템플릿 파일:
kubectl get pods <pod-name> -o custom-columns-file=template.txt
template.txt
파일에 포함된 내용은 다음과 같다.
NAME RSRC
metadata.name metadata.resourceVersion
두 명령 중 하나를 실행한 결과는 다음과 비슷하다.
NAME RSRC
submit-queue 610995
서버측 열
kubectl
는 서버에서 오브젝트에 대한 특정 열 정보 수신을 지원한다.
이는 클라이언트가 출력할 수 있도록, 주어진 리소스에 대해 서버가 해당 리소스와 관련된 열과 행을 반환한다는 것을 의미한다.
이는 서버가 출력의 세부 사항을 캡슐화하도록 하여, 동일한 클러스터에 대해 사용된 클라이언트에서 사람이 읽을 수 있는 일관된 출력을 허용한다.
이 기능은 기본적으로 활성화되어 있다. 사용하지 않으려면,
kubectl get
명령에 --server-print=false
플래그를 추가한다.
예제
파드 상태에 대한 정보를 출력하려면, 다음과 같은 명령을 사용한다.
kubectl get pods <pod-name> --server-print=false
출력 결과는 다음과 비슷하다.
NAME AGE
pod-name 1m
오브젝트 목록 정렬
터미널 창에서 정렬된 목록으로 오브젝트를 출력하기 위해, 지원되는 kubectl
명령에 --sort-by
플래그를 추가할 수 있다. --sort-by
플래그와 함께 숫자나 문자열 필드를 지정하여 오브젝트를 정렬한다. 필드를 지정하려면, jsonpath 표현식을 사용한다.
구문
kubectl [command] [TYPE] [NAME] --sort-by=<jsonpath_exp>
예제
이름별로 정렬된 파드 목록을 출력하려면, 다음을 실행한다.
kubectl get pods --sort-by=.metadata.name
예제: 일반적인 작업
다음 예제 세트를 사용하여 일반적으로 사용되는 kubectl
조작 실행에 익숙해진다.
kubectl apply
- 파일 또는 표준입력에서 리소스를 적용하거나 업데이트한다.
# example-service.yaml의 정의를 사용하여 서비스를 생성한다.
kubectl apply -f example-service.yaml
# example-controller.yaml의 정의를 사용하여 레플리케이션 컨트롤러를 생성한다.
kubectl apply -f example-controller.yaml
# <directory> 디렉터리 내의 .yaml, .yml 또는 .json 파일에 정의된 오브젝트를 생성한다.
kubectl apply -f <directory>
kubectl get
- 하나 이상의 리소스를 나열한다.
# 모든 파드를 일반 텍스트 출력 형식으로 나열한다.
kubectl get pods
# 모든 파드를 일반 텍스트 출력 형식으로 나열하고 추가 정보(예: 노드 이름)를 포함한다.
kubectl get pods -o wide
# 지정된 이름의 레플리케이션 컨트롤러를 일반 텍스트 출력 형식으로 나열한다. 팁: 'replicationcontroller' 리소스 타입을 'rc'로 짧게 바꿔쓸 수 있다.
kubectl get replicationcontroller <rc-name>
# 모든 레플리케이션 컨트롤러와 서비스를 일반 텍스트 출력 형식으로 함께 나열한다.
kubectl get rc,services
# 모든 데몬 셋을 일반 텍스트 출력 형식으로 나열한다.
kubectl get ds
# 노드 server01에서 실행 중인 모든 파드를 나열한다.
kubectl get pods --field-selector=spec.nodeName=server01
kubectl describe
- 초기화되지 않은 리소스를 포함하여 하나 이상의 리소스의 기본 상태를 디폴트로 표시한다.
# 노드 이름이 <node-name>인 노드의 세부 사항을 표시한다.
kubectl describe nodes <node-name>
# 파드 이름이 <pod-name> 인 파드의 세부 정보를 표시한다.
kubectl describe pods/<pod-name>
# 이름이 <rc-name>인 레플리케이션 컨트롤러가 관리하는 모든 파드의 세부 정보를 표시한다.
# 기억하기: 레플리케이션 컨트롤러에서 생성된 모든 파드에는 레플리케이션 컨트롤러 이름이 접두사로 붙는다.
kubectl describe pods <rc-name>
# 모든 파드의 정보를 출력한다.
kubectl describe pods
kubectl get
명령은 일반적으로 동일한 리소스 타입의 하나 이상의
리소스를 검색하는 데 사용된다. 예를 들어, -o
또는 --output
플래그를
사용하여 출력 형식을 사용자 정의할 수 있는 풍부한 플래그 세트가 있다.
-w
또는 --watch
플래그를 지정하여 특정 오브젝트에 대한 업데이트 진행과정을 확인할 수
있다. kubectl describe
명령은 지정된 리소스의 여러 관련 측면을
설명하는 데 더 중점을 둔다. API 서버에 대한 여러 API 호출을 호출하여
사용자에 대한 뷰(view)를 빌드할 수 있다. 예를 들어, kubectl describe node
명령은 노드에 대한 정보뿐만 아니라, 노드에서 실행 중인 파드의 요약 정보, 노드에 대해 생성된 이벤트 등의
정보도 검색한다.
kubectl delete
- 파일, 표준입력 또는 레이블 선택기, 이름, 리소스 선택기나 리소스를 지정하여 리소스를 삭제한다.
# pod.yaml 파일에 지정된 타입과 이름을 사용하여 파드를 삭제한다.
kubectl delete -f pod.yaml
# '<label-key>=<label-value>' 레이블이 있는 모든 파드와 서비스를 삭제한다.
kubectl delete pods,services -l <label-key>=<label-value>
# 초기화되지 않은 파드를 포함한 모든 파드를 삭제한다.
kubectl delete pods --all
kubectl exec
- 파드의 컨테이너에 대해 명령을 실행한다.
# 파드 <pod-name>에서 'date'를 실행한 결과를 얻는다. 기본적으로, 첫 번째 컨테이너에서 출력된다.
kubectl exec <pod-name> -- date
# 파드 <pod-name>의 <container-name> 컨테이너에서 'date'를 실행하여 출력 결과를 얻는다.
kubectl exec <pod-name> -c <container-name> -- date
# 파드 <pod-name>에서 대화식 TTY를 연결해 /bin/bash를 실행한다. 기본적으로, 첫 번째 컨테이너에서 출력된다.
kubectl exec -ti <pod-name> -- /bin/bash
kubectl logs
- 파드의 컨테이너에 대한 로그를 출력한다.
# 파드 <pod-name>에서 로그의 스냅샷을 반환한다.
kubectl logs <pod-name>
# 파드 <pod-name>에서 로그 스트리밍을 시작한다. 이것은 리눅스 명령 'tail -f'와 비슷하다.
kubectl logs -f <pod-name>
kubectl diff
- 제안된 클러스터 업데이트의 차이점을 본다.
# "pod.json"에 포함된 리소스의 차이점을 출력한다.
kubectl diff -f pod.json
# 표준입력에서 파일을 읽어 차이점을 출력한다.
cat service.yaml | kubectl diff -f -
예제: 플러그인 작성 및 사용
kubectl
플러그인 작성과 사용에 익숙해지려면 다음의 예제 세트를 사용한다.
# 어떤 언어로든 간단한 플러그인을 만들고 "kubectl-" 접두사로
# 시작하도록 실행 파일의 이름을 지정한다.
cat ./kubectl-hello
#!/bin/sh
# 이 플러그인은 "hello world"라는 단어를 출력한다
echo "hello world"
작성한 플러그인을 실행 가능하게 한다
chmod a+x ./kubectl-hello
# 그리고 PATH의 위치로 옮긴다
sudo mv ./kubectl-hello /usr/local/bin
sudo chown root:root /usr/local/bin
# 이제 kubectl 플러그인을 만들고 "설치했다".
# kubectl에서 플러그인을 일반 명령처럼 호출하여 플러그인을 사용할 수 있다
kubectl hello
hello world
# 플러그인을 배치한 $PATH의 폴더에서 플러그인을 삭제하여,
# 플러그인을 "제거"할 수 있다
sudo rm /usr/local/bin/kubectl-hello
kubectl
에 사용할 수 있는 모든 플러그인을 보려면,
kubectl plugin list
하위 명령을 사용한다.
kubectl plugin list
출력 결과는 다음과 비슷하다.
The following kubectl-compatible plugins are available:
/usr/local/bin/kubectl-hello
/usr/local/bin/kubectl-foo
/usr/local/bin/kubectl-bar
kubectl plugin list
는 또한 실행 가능하지 않거나,
다른 플러그인에 의해 차단된 플러그인에 대해 경고한다. 예를 들면 다음과 같다.
sudo chmod -x /usr/local/bin/kubectl-foo # 실행 권한 제거
kubectl plugin list
The following kubectl-compatible plugins are available:
/usr/local/bin/kubectl-hello
/usr/local/bin/kubectl-foo
- warning: /usr/local/bin/kubectl-foo identified as a plugin, but it is not executable
/usr/local/bin/kubectl-bar
error: one plugin warning was found
플러그인은 기존 kubectl 명령 위에 보다 복잡한 기능을 구축하는 수단으로 생각할 수 있다.
cat ./kubectl-whoami
다음 몇 가지 예는 이미 kubectl-whoami
에
다음 내용이 있다고 가정한다.
#!/bin/bash
# 이 플러그인은 현재 선택된 컨텍스트를 기반으로 현재 사용자에 대한
# 정보를 출력하기 위해 'kubectl config' 명령을 사용한다.
kubectl config view --template='{{ range .contexts }}{{ if eq .name "'$(kubectl config current-context)'" }}Current user: {{ printf "%s\n" .context.user }}{{ end }}{{ end }}'
위의 플러그인을 실행하면 KUBECONFIG 파일에서 현재의 컨텍스트에 대한 사용자가 포함된 출력이 제공된다.
# 파일을 실행 가능하게 한다
sudo chmod +x ./kubectl-whoami
# 그리고 PATH로 옮긴다
sudo mv ./kubectl-whoami /usr/local/bin
kubectl whoami
Current user: plugins-user
다음 내용
-
kubectl 명령을 사용하여 시작한다.
-
플러그인에 대한 자세한 내용은 cli plugin 예제를 참고한다.
2 - JSONPath 지원
Kubectl은 JSONPath 템플릿을 지원한다.
JSONPath 템플릿은 중괄호 {}로 둘러싸인 JSONPath 표현식으로 구성된다. Kubectl은 JSONPath 표현식을 사용하여 JSON 오브젝트의 특정 필드를 필터링하고 출력 형식을 지정한다. 원본 JSONPath 템플릿 구문 외에도 다음과 같은 기능과 구문이 유효하다.
- 큰따옴표를 사용하여 JSONPath 표현식 내부의 텍스트를 인용한다.
- 목록을 반복하려면
range
,end
오퍼레이터를 사용한다. - 목록에서 뒤로 이동하려면 negative slice 인덱스를 사용한다. negative 인덱스는 목록을 "순환(wrap around)" 하지 않으며,
-index + listLength >= 0
인 한 유효하다.
-
표현식은 항상 루트 오브젝트에서 시작하므로
$
오퍼레이터는 선택 사항이다. -
결과 오브젝트는 String() 함수로 출력된다.
JSON 입력 시 다음과 같다.
{
"kind": "List",
"items":[
{
"kind":"None",
"metadata":{"name":"127.0.0.1"},
"status":{
"capacity":{"cpu":"4"},
"addresses":[{"type": "LegacyHostIP", "address":"127.0.0.1"}]
}
},
{
"kind":"None",
"metadata":{"name":"127.0.0.2"},
"status":{
"capacity":{"cpu":"8"},
"addresses":[
{"type": "LegacyHostIP", "address":"127.0.0.2"},
{"type": "another", "address":"127.0.0.3"}
]
}
}
],
"users":[
{
"name": "myself",
"user": {}
},
{
"name": "e2e",
"user": {"username": "admin", "password": "secret"}
}
]
}
Function | Description | Example | Result |
---|---|---|---|
text |
일반 텍스트 | kind is {.kind} |
kind is List |
@ |
현재 오브젝트 | {@} |
입력과 동일 |
. or [] |
자식 오퍼레이터 | {.kind} , {['kind']} or {['name\.type']} |
List |
.. |
재귀 하향(recursive descent) | {..name} |
127.0.0.1 127.0.0.2 myself e2e |
* |
와일드 카드. 모든 오브젝트 가져오기 | {.items[*].metadata.name} |
[127.0.0.1 127.0.0.2] |
[start:end:step] |
아래 첨자 오퍼레이터 | {.users[0].name} |
myself |
[,] |
조합 오퍼레이터 | {.items[*]['metadata.name', 'status.capacity']} |
127.0.0.1 127.0.0.2 map[cpu:4] map[cpu:8] |
?() |
필터 | {.users[?(@.name=="e2e")].user.password} |
secret |
range , end |
반복 목록 | {range .items[*]}[{.metadata.name}, {.status.capacity}] {end} |
[127.0.0.1, map[cpu:4]] [127.0.0.2, map[cpu:8]] |
'' |
해석된 문자열 인용 | {range .items[*]}{.metadata.name}{'\t'}{end} |
127.0.0.1 127.0.0.2 |
kubectl
및 JSONPath 표현식을 사용하는 예는 다음과 같다.
kubectl get pods -o json
kubectl get pods -o=jsonpath='{@}'
kubectl get pods -o=jsonpath='{.items[0]}'
kubectl get pods -o=jsonpath='{.items[0].metadata.name}'
kubectl get pods -o=jsonpath="{.items[*]['metadata.name', 'status.capacity']}"
kubectl get pods -o=jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.startTime}{"\n"}{end}'
윈도우에서 공백이 포함된 JSONPath 템플릿을 큰따옴표(위의 bash에 표시된 작은따옴표가 아님)로 묶어야 한다. 즉, 템플릿의 모든 문자 주변에 작은따옴표 또는 이스케이프된 큰따옴표를 사용해야 한다. 예를 들면, 다음과 같다.
kubectl get pods -o=jsonpath="{range .items[*]}{.metadata.name}{'\t'}{.status.startTime}{'\n'}{end}"
kubectl get pods -o=jsonpath="{range .items[*]}{.metadata.name}{\"\t\"}{.status.startTime}{\"\n\"}{end}"
JSONPath 정규식은 지원되지 않는다. 정규 표현식을 이용해 매치하려면 jq
와 같은 도구를 사용하면 된다.
# kubectl은 JSONPath 출력에 대한 정규 표현식을 지원하지 않는다.
# 다음 커맨드는 작동하지 않는다.
kubectl get pods -o jsonpath='{.items[?(@.metadata.name=~/^test$/)].metadata.name}'
# 다음 커맨드는 원하는 결과를 얻는다.
kubectl get pods -o json | jq -r '.items[] | select(.metadata.name | test("test-")).spec.containers[].image'
3 - kubectl
시놉시스
kubectl은 쿠버네티스 클러스터 관리자를 제어한다.
자세한 정보는 kubectl 개요를 확인한다.
kubectl [flags]
옵션
--add-dir-header | |
true인 경우, 로그 메시지의 헤더에 파일 디렉터리를 추가한다. | |
--alsologtostderr | |
표준 에러와 파일에 로그를 기록한다. | |
--as string | |
작업을 수행할 사용자 이름 | |
--as-group stringArray | |
작업을 수행할 그룹. 이 플래그를 반복해서 여러 그룹을 지정할 수 있다. | |
--azure-container-registry-config string | |
Azure 컨테이너 레지스트리 구성 정보가 포함된 파일의 경로이다. | |
--cache-dir string 기본값: "$HOME/.kube/cache" | |
기본 캐시 디렉터리 | |
--certificate-authority string | |
인증 기관의 인증서에 대한 파일 경로 | |
--client-certificate string | |
TLS용 클라이언트 인증서의 파일 경로 | |
--client-key string | |
TLS용 클라이언트 키의 파일 경로 | |
--cloud-provider-gce-l7lb-src-cidrs cidrs 기본값: 130.211.0.0/22,35.191.0.0/16 | |
L7 LB 트래픽 프록시 및 상태 확인을 위해 GCE 방화벽에서 오픈된 CIDR | |
--cloud-provider-gce-lb-src-cidrs cidrs 기본값: 130.211.0.0/22,209.85.152.0/22,209.85.204.0/22,35.191.0.0/16 | |
L4 LB 트래픽 프록시 및 상태 확인을 위해 GCE 방화벽에서 오픈된 CIDR | |
--cluster string | |
사용할 kubeconfig 클러스터의 이름 | |
--context string | |
사용할 kubeconfig 콘텍스트의 이름 | |
--default-not-ready-toleration-seconds int 기본값: 300 | |
아직 톨러레이션(toleration)이 없는 모든 파드에 기본적으로 추가되는 notReady:NoExecute에 대한 톨러레이션의 tolerationSeconds를 나타낸다. | |
--default-unreachable-toleration-seconds int 기본값: 300 | |
아직 톨러레이션이 없어서 기본인 unreachable:NoExecute가 추가된 모든 파드에 대한 톨러레이션의 tolerationSeconds를 나타낸다. | |
-h, --help | |
kubectl에 대한 도움말 | |
--insecure-skip-tls-verify | |
true인 경우, 서버 인증서의 유효성을 확인하지 않는다. 이렇게 하면 사용자의 HTTPS 연결이 안전하지 않게 된다. | |
--kubeconfig string | |
CLI 요청에 사용할 kubeconfig 파일의 경로이다. | |
--log-backtrace-at traceLocation 기본값: :0 | |
로깅이 file:N에 도달했을 때 스택 트레이스를 내보낸다. | |
--log-dir string | |
비어 있지 않으면, 이 디렉터리에 로그 파일을 작성한다. | |
--log-file string | |
비어 있지 않으면, 이 로그 파일을 사용한다. | |
--log-file-max-size uint 기본값: 1800 | |
로그 파일이 커질 수 있는 최대 크기를 정의한다. 단위는 메가 바이트이다. 값이 0이면, 파일의 최대 크기는 무제한이다. | |
--log-flush-frequency duration 기본값: 5s | |
로그를 비우는 간격의 최대 시간(초) | |
--logtostderr 기본값: true | |
파일 대신 표준 에러에 기록 | |
--match-server-version | |
클라이언트 버전과 일치하는 서버 버전 필요 | |
-n, --namespace string | |
지정된 경우, 해당 네임스페이스가 CLI 요청의 범위가 됨 | |
--one-output | |
true이면, 로그를 기본 심각도 수준으로만 기록한다(그렇지 않으면 각각의 더 낮은 심각도 수준에도 기록함). | |
--password string | |
API 서버에 대한 기본 인증을 위한 비밀번호 | |
--profile string 기본값: "none" | |
캡처할 프로파일의 이름. (none|cpu|heap|goroutine|threadcreate|block|mutex) 중 하나 | |
--profile-output string 기본값: "profile.pprof" | |
프로파일을 쓸 파일의 이름 | |
--request-timeout string 기본값: "0" | |
단일 서버 요청을 포기하기 전에 대기하는 시간이다. 0이 아닌 값에는 해당 시간 단위(예: 1s, 2m, 3h)가 포함되어야 한다. 값이 0이면 요청 시간이 초과되지 않는다. | |
-s, --server string | |
쿠버네티스 API 서버의 주소와 포트 | |
--skip-headers | |
true이면, 로그 메시지에서 헤더 접두사를 사용하지 않는다. | |
--skip-log-headers | |
true이면, 로그 파일을 열 때 헤더를 사용하지 않는다. | |
--stderrthreshold severity 기본값: 2 | |
이 임계값 이상의 로그는 표준 에러로 이동한다. | |
--tls-server-name string | |
서버 인증서 유효성 검사에 사용할 서버 이름. 제공되지 않으면, 서버에 접속하는 데 사용되는 호스트 이름이 사용된다. | |
--token string | |
API 서버 인증을 위한 베어러(Bearer) 토큰 | |
--user string | |
사용할 kubeconfig 사용자의 이름 | |
--username string | |
API 서버에 대한 기본 인증을 위한 사용자 이름 | |
-v, --v Level | |
로그 수준의 자세한 정도를 나타내는 숫자 | |
--version version[=true] | |
버전 정보를 출력하고 종료 | |
--vmodule moduleSpec | |
파일 필터링 로깅을 위한 쉼표로 구분된 pattern=N 설정 목록 | |
--warnings-as-errors | |
서버에서 받은 경고를 오류로 처리하고 0이 아닌 종료 코드로 종료 |
Environment variables
KUBECONFIG | |
kubectl 구성 ("kubeconfig") 파일 경로. 기본: "$HOME/.kube/config" | |
KUBECTL_COMMAND_HEADERS | |
false로 설정하면, 호출된 kubectl 명령(쿠버네티스 버전 v1.22 이상)을 자세히 설명하는 추가 HTTP 헤더를 해제 |
더 보기
- kubectl annotate - 리소스에 대한 어노테이션 업데이트
- kubectl api-resources - 서버에서 지원되는 API 리소스 출력
- kubectl api-versions - "그룹/버전" 형식으로 서버에서 지원되는 API 버전을 출력
- kubectl apply - 파일명 또는 표준 입력으로 리소스에 구성 적용
- kubectl attach - 실행 중인 컨테이너에 연결
- kubectl auth - 권한 검사
- kubectl autoscale - 디플로이먼트(Deployment), 레플리카셋(ReplicaSet) 또는 레플리케이션컨트롤러(ReplicationController) 자동 스케일링
- kubectl certificate - 인증서 리소스 수정
- kubectl cluster-info - 클러스터 정보 표시
- kubectl completion - 지정된 셸(bash 또는 zsh)에 대한 셸 완성 코드 출력
- kubectl config - kubeconfig 파일 수정
- kubectl cordon - 노드를 unschedulable로 표시
- kubectl cp - 컨테이너 간에 파일과 디렉터리 복사
- kubectl create - 파일 또는 표준 입력에서 리소스를 생성
- kubectl debug - 워크로드와 노드의 문제 해결을 위한 디버깅 세션 생성
- kubectl delete - 파일명, 표준 입력, 리소스 및 이름, 또는 리소스 및 레이블 셀렉터로 리소스 삭제
- kubectl describe - 특정 리소스 또는 리소스 그룹의 세부 정보를 표시
- kubectl diff - 적용 예정 버전과 라이브 버전 비교
- kubectl drain - 유지 보수 준비 중 노드 드레인
- kubectl edit - 서버에서 리소스 편집
- kubectl exec - 컨테이너에서 커맨드 실행
- kubectl explain - 리소스의 문서
- kubectl expose - 레플리케이션 컨트롤러, 서비스, 디플로이먼트 또는 파드를 가져와서 새로운 쿠버네티스 서비스로 노출
- kubectl get - 하나 이상의 리소스 표시
- kubectl kustomize - 디렉터리 또는 원격 URL에서 kustomization 대상을 빌드
- kubectl label - 리소스의 레이블 업데이트
- kubectl logs - 파드의 컨테이너에 대한 로그 출력
- kubectl options - 모든 커맨드에서 상속된 플래그 목록을 출력
- kubectl patch - 리소스 필드를 업데이트
- kubectl plugin - 플러그인과 상호 작용하기 위한 유틸리티를 제공
- kubectl port-forward - 하나 이상의 로컬 포트를 파드로 전달
- kubectl proxy - 쿠버네티스 API 서버에 대한 프록시 실행
- kubectl replace - 파일명 또는 표준 입력으로 리소스 교체
- kubectl rollout - 리소스 롤아웃 관리
- kubectl run - 클러스터에서 특정 이미지 실행
- kubectl scale - 디플로이먼트, 레플리카셋 또는 레플리케이션 컨트롤러의 새 크기 설정
- kubectl set - 오브젝트에 특정 기능 설정
- kubectl taint - 하나 이상의 노드에서 테인트(taint) 업데이트
- kubectl top - 리소스(CPU/메모리/스토리지) 사용량을 표시
- kubectl uncordon - 노드를 schedulable로 표시
- kubectl version - 클라이언트 및 서버 버전 정보 출력
- kubectl wait - 실험적(experimental) 기능: 하나 이상의 리소스에 대해서 특정 조건이 만족될 때까지 대기(wait)
4 - kubectl 사용 규칙
kubectl
에 대한 권장 사용 규칙.
재사용 가능한 스크립트에서 kubectl
사용
스크립트의 안정적인 출력을 위해서
-o name
,-o json
,-o yaml
,-o go-template
혹은-o jsonpath
와 같은 머신 지향(machine-oriented) 출력 양식 중 하나를 요청한다.- 예를 들어
jobs.v1.batch/myjob
과 같이 전체 버전을 사용한다. 이를 통해kubectl
이 시간이 지남에 따라 변경될 수 있는 기본 버전을 사용하지 않도록 한다. - 문맥, 설정 또는 기타 암묵적 상태에 의존하지 않는다.
모범 사례
kubectl run
kubectl run
으로 infrastructure as code를 충족시키기 위해서
- 버전이 명시된 태그로 이미지를 태그하고 그 태그를 새로운 버전으로 이동하지 않는다. 예를 들어,
:latest
가 아닌:v1234
,v1.2.3
,r03062016-1-4
를 사용한다(자세한 정보는 구성 모범 사례를 참고한다). - 많은 파라미터가 적용된 이미지를 위한 스크립트를 작성한다.
- 필요하지만
kubectl run
플래그를 통해 표현할 수 없는 기능은 구성 파일을 소스 코드 버전 관리 시스템에 넣어서 전환한다.
--dry-run
플래그를 사용하여 실제로 제출하지 않고 클러스터로 보낼 오브젝트를 미리 볼 수 있다.
kubectl run
의 생성기(generator)는 더 이상 사용 할 수 없다. 생성기 목록 및 사용 방법은 쿠버네티스 v1.17 문서를 참고한다.
생성기
kubectl create --dry-run -o yaml
라는 kubectl 커맨드를 통해 다음과 같은 리소스를 생성할 수 있다.
clusterrole
: 클러스터롤(ClusterRole)를 생성한다.clusterrolebinding
: 특정 클러스터롤에 대한 클러스터롤바인딩(ClusterRoleBinding)을 생성한다.configmap
: 로컬 파일, 디렉토리 또는 문자 그대로의 값으로 컨피그맵(ConfigMap)을 생성한다.cronjob
: 지정된 이름으로 크론잡(CronJob)을 생성한다.deployment
: 지정된 이름으로 디플로이먼트(Deployment)를 생성한다.job
: 지정된 이름으로 잡(Job)을 생성한다.namespace
: 지정된 이름으로 네임스페이스(Namespace)를 생성한다.poddisruptionbudget
: 지정된 이름으로 PodDisruptionBudget을 생성한다.priorityclass
: 지정된 이름으로 프라이어리티클래스(PriorityClass)을 생성한다.quota
: 지정된 이름으로 쿼터(Quota)를 생성한다.role
: 단일 규칙으로 롤(Role)을 생성한다.rolebinding
: 특정 롤 또는 클러스터롤에 대한 롤바인딩(RoleBinding)을 생성한다.secret
: 지정된 하위 커맨드를 사용하여 시크릿(Secret)을 생성한다.service
: 지정된 하위 커맨드를 사용하여 서비스(Service)를 생성한다.serviceaccount
: 지정된 이름으로 서비스어카운트(ServiceAccount)을 생성한다.
kubectl apply
kubectl apply
를 사용해서 리소스를 생성하거나 업데이트 할 수 있다. kubectl apply를 사용하여 리소스를 업데이트하는 방법에 대한 자세한 정보는 Kubectl 책을 참고한다.
5 - kubectl 치트 시트
이 페이지는 일반적으로 사용하는 kubectl
커맨드와 플래그에 대한 목록을 포함한다.
Kubectl 자동 완성
BASH
source <(kubectl completion bash) # bash-completion 패키지를 먼저 설치한 후, bash의 자동 완성을 현재 셸에 설정한다
echo "source <(kubectl completion bash)" >> ~/.bashrc # 자동 완성을 bash 셸에 영구적으로 추가한다
또한, kubectl
의 의미로 사용되는 약칭을 사용할 수 있다.
alias k=kubectl
complete -F __start_kubectl k
ZSH
source <(kubectl completion zsh) # 현재 셸에 zsh의 자동 완성 설정
echo "[[ $commands[kubectl] ]] && source <(kubectl completion zsh)" >> ~/.zshrc # 자동 완성을 zsh 셸에 영구적으로 추가한다.
Kubectl 컨텍스트와 설정
kubectl
이 통신하고 설정 정보를 수정하는 쿠버네티스 클러스터를
지정한다. 설정 파일에 대한 자세한 정보는 kubeconfig를 이용한 클러스터 간 인증 문서를
참고한다.
kubectl config view # 병합된 kubeconfig 설정을 표시한다.
# 동시에 여러 kubeconfig 파일을 사용하고 병합된 구성을 확인한다
KUBECONFIG=~/.kube/config:~/.kube/kubconfig2
kubectl config view
# e2e 사용자의 암호를 확인한다
kubectl config view -o jsonpath='{.users[?(@.name == "e2e")].user.password}'
kubectl config view -o jsonpath='{.users[].name}' # 첫 번째 사용자 출력
kubectl config view -o jsonpath='{.users[*].name}' # 사용자 리스트 조회
kubectl config get-contexts # 컨텍스트 리스트 출력
kubectl config current-context # 현재 컨텍스트 출력
kubectl config use-context my-cluster-name # my-cluster-name를 기본 컨텍스트로 설정
# 기본 인증을 지원하는 새로운 사용자를 kubeconf에 추가한다
kubectl config set-credentials kubeuser/foo.kubernetes.com --username=kubeuser --password=kubepassword
# 해당 컨텍스트에서 모든 후속 kubectl 커맨드에 대한 네임스페이스를 영구적으로 저장한다
kubectl config set-context --current --namespace=ggckad-s2
# 특정 사용자와 네임스페이스를 사용하는 컨텍스트 설정
kubectl config set-context gce --user=cluster-admin --namespace=foo \
&& kubectl config use-context gce
kubectl config unset users.foo # foo 사용자 삭제
Kubectl apply
apply
는 쿠버네티스 리소스를 정의하는 파일을 통해 애플리케이션을 관리한다. kubectl apply
를 실행하여 클러스터에 리소스를 생성하고 업데이트한다. 이것은 프로덕션 환경에서 쿠버네티스 애플리케이션을 관리할 때 권장된다. Kubectl Book을 참고한다.
오브젝트 생성
쿠버네티스 매니페스트는 JSON이나 YAML로 정의된다. 파일 확장자는 .yaml
, .yml
, .json
이 사용된다.
kubectl apply -f ./my-manifest.yaml # 리소스(들) 생성
kubectl apply -f ./my1.yaml -f ./my2.yaml # 여러 파일로 부터 생성
kubectl apply -f ./dir # dir 내 모든 매니페스트 파일에서 리소스(들) 생성
kubectl apply -f https://git.io/vPieo # url로부터 리소스(들) 생성
kubectl create deployment nginx --image=nginx # nginx 단일 인스턴스를 시작
# "Hello World"를 출력하는 잡(Job) 생성
kubectl create job hello --image=busybox -- echo "Hello World"
# 매분마다 "Hello World"를 출력하는 크론잡(CronJob) 생성
kubectl create cronjob hello --image=busybox --schedule="*/1 * * * *" -- echo "Hello World"
kubectl explain pods # 파드 매니페스트 문서를 조회
# stdin으로 다수의 YAML 오브젝트 생성
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
name: busybox-sleep
spec:
containers:
- name: busybox
image: busybox
args:
- sleep
- "1000000"
---
apiVersion: v1
kind: Pod
metadata:
name: busybox-sleep-less
spec:
containers:
- name: busybox
image: busybox
args:
- sleep
- "1000"
EOF
# 여러 개의 키로 시크릿 생성
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
password: $(echo -n "s33msi4" | base64 -w0)
username: $(echo -n "jane" | base64 -w0)
EOF
리소스 조회 및 찾기
# 기본 출력을 위한 Get 커맨드
kubectl get services # 네임스페이스 내 모든 서비스의 목록 조회
kubectl get pods --all-namespaces # 모든 네임스페이스 내 모든 파드의 목록 조회
kubectl get pods -o wide # 해당하는 네임스페이스 내 모든 파드의 상세 목록 조회
kubectl get deployment my-dep # 특정 디플로이먼트의 목록 조회
kubectl get pods # 네임스페이스 내 모든 파드의 목록 조회
kubectl get pod my-pod -o yaml # 파드의 YAML 조회
# 상세 출력을 위한 Describe 커맨드
kubectl describe nodes my-node
kubectl describe pods my-pod
# Name으로 정렬된 서비스의 목록 조회
kubectl get services --sort-by=.metadata.name
# 재시작 횟수로 정렬된 파드의 목록 조회
kubectl get pods --sort-by='.status.containerStatuses[0].restartCount'
# PersistentVolumes을 용량별로 정렬해서 조회
kubectl get pv --sort-by=.spec.capacity.storage
# app=cassandra 레이블을 가진 모든 파드의 레이블 버전 조회
kubectl get pods --selector=app=cassandra -o \
jsonpath='{.items[*].metadata.labels.version}'
# 예를 들어 'ca.crt'와 같이 점이 있는 키값을 검색한다
kubectl get configmap myconfig \
-o jsonpath='{.data.ca\.crt}'
# 모든 워커 노드 조회 (셀렉터를 사용하여 'node-role.kubernetes.io/master'
# 으로 명명된 라벨의 결과를 제외)
kubectl get node --selector='!node-role.kubernetes.io/master'
# 네임스페이스의 모든 실행 중인 파드를 조회
kubectl get pods --field-selector=status.phase=Running
# 모든 노드의 외부IP를 조회
kubectl get nodes -o jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}'
# 특정 RC에 속해있는 파드 이름의 목록 조회
# "jq" 커맨드는 jsonpath를 사용하는 매우 복잡한 변환에 유용하다. https://stedolan.github.io/jq/ 에서 확인할 수 있다.
sel=${$(kubectl get rc my-rc --output=json | jq -j '.spec.selector | to_entries | .[] | "\(.key)=\(.value),"')%?}
echo $(kubectl get pods --selector=$sel --output=jsonpath={.items..metadata.name})
# 모든 파드(또는 레이블을 지원하는 다른 쿠버네티스 오브젝트)의 레이블 조회
kubectl get pods --show-labels
# 어떤 노드가 준비됐는지 확인
JSONPATH='{range .items[*]}{@.metadata.name}:{range @.status.conditions[*]}{@.type}={@.status};{end}{end}' \
&& kubectl get nodes -o jsonpath="$JSONPATH" | grep "Ready=True"
# 외부 도구 없이 디코딩된 시크릿 출력
kubectl get secret my-secret -o go-template='{{range $k,$v := .data}}{{"### "}}{{$k}}{{"\n"}}{{$v|base64decode}}{{"\n\n"}}{{end}}'
# 파드에 의해 현재 사용되고 있는 모든 시크릿 목록 조회
kubectl get pods -o json | jq '.items[].spec.containers[].env[]?.valueFrom.secretKeyRef.name' | grep -v null | sort | uniq
# 모든 파드의 초기화 컨테이너(initContainer)의 컨테이너ID 목록 조회
# 초기화 컨테이너(initContainer)를 제거하지 않고 정지된 모든 컨테이너를 정리할 때 유용하다.
kubectl get pods --all-namespaces -o jsonpath='{range .items[*].status.initContainerStatuses[*]}{.containerID}{"\n"}{end}' | cut -d/ -f3
# 타임스탬프로 정렬된 이벤트 목록 조회
kubectl get events --sort-by=.metadata.creationTimestamp
# 매니페스트가 적용된 경우 클러스터의 현재 상태와 클러스터의 상태를 비교한다.
kubectl diff -f ./my-manifest.yaml
# 노드에 대해 반환된 모든 키의 마침표로 구분된 트리를 생성한다.
# 복잡한 중첩 JSON 구조 내에서 키를 찾을 때 유용하다.
kubectl get nodes -o json | jq -c 'path(..)|[.[]|tostring]|join(".")'
# 파드 등에 대해 반환된 모든 키의 마침표로 구분된 트리를 생성한다.
kubectl get pods -o json | jq -c 'path(..)|[.[]|tostring]|join(".")'
# 모든 파드에 대해 ENV를 생성한다(각 파드에 기본 컨테이너가 있고, 기본 네임스페이스가 있고, `env` 명령어가 동작한다고 가정).
# `env` 뿐만 아니라 다른 지원되는 명령어를 모든 파드에 실행할 때에도 참고할 수 있다.
for pod in $(kubectl get po --output=jsonpath={.items..metadata.name}); do echo $pod && kubectl exec -it $pod -- env; done
리소스 업데이트
kubectl set image deployment/frontend www=image:v2 # "frontend" 디플로이먼트의 "www" 컨테이너 이미지를 업데이트하는 롤링 업데이트
kubectl rollout history deployment/frontend # 현 리비전을 포함한 디플로이먼트의 이력을 체크
kubectl rollout undo deployment/frontend # 이전 디플로이먼트로 롤백
kubectl rollout undo deployment/frontend --to-revision=2 # 특정 리비전으로 롤백
kubectl rollout status -w deployment/frontend # 완료될 때까지 "frontend" 디플로이먼트의 롤링 업데이트 상태를 감시
kubectl rollout restart deployment/frontend # "frontend" 디플로이먼트의 롤링 재시작
cat pod.json | kubectl replace -f - # std로 전달된 JSON을 기반으로 파드 교체
# 리소스를 강제 교체, 삭제 후 재생성함. 이것은 서비스를 중단시킴.
kubectl replace --force -f ./pod.json
# 복제된 nginx를 위한 서비스를 생성한다. 80 포트로 서비스하고, 컨테이너는 8000 포트로 연결한다.
kubectl expose rc nginx --port=80 --target-port=8000
# 단일-컨테이너 파드의 이미지 버전(태그)을 v4로 업데이트
kubectl get pod mypod -o yaml | sed 's/\(image: myimage\):.*$/\1:v4/' | kubectl replace -f -
kubectl label pods my-pod new-label=awesome # 레이블 추가
kubectl annotate pods my-pod icon-url=http://goo.gl/XXBTWq # 어노테이션 추가
kubectl autoscale deployment foo --min=2 --max=10 # 디플로이먼트 "foo" 오토스케일
리소스 패치
kubectl patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}' # 노드를 부분적으로 업데이트
# 컨테이너의 이미지를 업데이트. 병합(merge) 키이므로, spec.containers[*].name이 필요.
kubectl patch pod valid-pod -p '{"spec":{"containers":[{"name":"kubernetes-serve-hostname","image":"new image"}]}}'
# 위치 배열을 이용한 json 패치를 사용하여, 컨테이너의 이미지를 업데이트.
kubectl patch pod valid-pod --type='json' -p='[{"op": "replace", "path": "/spec/containers/0/image", "value":"new image"}]'
# 위치 배열을 이용한 json 패치를 사용하여 livenessProbe 디플로이먼트 비활성화.
kubectl patch deployment valid-deployment --type json -p='[{"op": "remove", "path": "/spec/template/spec/containers/0/livenessProbe"}]'
# 위치 배열에 새 요소 추가
kubectl patch sa default --type='json' -p='[{"op": "add", "path": "/secrets/1", "value": {"name": "whatever" } }]'
리소스 편집
편집기로 모든 API 리소스를 편집.
kubectl edit svc/docker-registry # docker-registry라는 서비스 편집
KUBE_EDITOR="nano" kubectl edit svc/docker-registry # 다른 편집기 사용
리소스 스케일링
kubectl scale --replicas=3 rs/foo # 'foo'라는 레플리카셋을 3으로 스케일
kubectl scale --replicas=3 -f foo.yaml # "foo.yaml"에 지정된 리소스의 크기를 3으로 스케일
kubectl scale --current-replicas=2 --replicas=3 deployment/mysql # mysql이라는 디플로이먼트의 현재 크기가 2인 경우, mysql을 3으로 스케일
kubectl scale --replicas=5 rc/foo rc/bar rc/baz # 여러 개의 레플리케이션 컨트롤러 스케일
리소스 삭제
kubectl delete -f ./pod.json # pod.json에 지정된 유형 및 이름을 사용하여 파드 삭제
kubectl delete pod unwanted --now # 유예 시간 없이 즉시 파드 삭제
kubectl delete pod,service baz foo # "baz", "foo"와 동일한 이름을 가진 파드와 서비스 삭제
kubectl delete pods,services -l name=myLabel # name=myLabel 라벨을 가진 파드와 서비스 삭제
kubectl -n my-ns delete pod,svc --all # my-ns 네임스페이스 내 모든 파드와 서비스 삭제
# awk pattern1 또는 pattern2에 매칭되는 모든 파드 삭제
kubectl get pods -n mynamespace --no-headers=true | awk '/pattern1|pattern2/{print $1}' | xargs kubectl delete -n mynamespace pod
실행 중인 파드와 상호 작용
kubectl logs my-pod # 파드 로그 덤프 (stdout)
kubectl logs -l name=myLabel # name이 myLabel인 파드 로그 덤프 (stdout)
kubectl logs my-pod --previous # 컨테이너의 이전 인스턴스 생성에 대한 파드 로그 덤프 (stdout)
kubectl logs my-pod -c my-container # 파드 로그 덤프 (stdout, 멀티-컨테이너 경우)
kubectl logs -l name=myLabel -c my-container # name이 myLabel인 파드 로그 덤프 (stdout)
kubectl logs my-pod -c my-container --previous # 컨테이너의 이전 인스턴스 생성에 대한 파드 로그 덤프 (stdout, 멀티-컨테이너 경우)
kubectl logs -f my-pod # 실시간 스트림 파드 로그(stdout)
kubectl logs -f my-pod -c my-container # 실시간 스트림 파드 로그(stdout, 멀티-컨테이너 경우)
kubectl logs -f -l name=myLabel --all-containers # name이 myLabel인 모든 파드의 로그 스트리밍 (stdout)
kubectl run -i --tty busybox --image=busybox -- sh # 대화형 셸로 파드를 실행
kubectl run nginx --image=nginx -n mynamespace # mynamespace 네임스페이스에서 nginx 파드 1개 실행
kubectl run nginx --image=nginx # nginx 파드를 실행하고 해당 스펙을 pod.yaml 파일에 기록
--dry-run=client -o yaml > pod.yaml
kubectl attach my-pod -i # 실행 중인 컨테이너에 연결
kubectl port-forward my-pod 5000:6000 # 로컬 머신의 5000번 포트를 리스닝하고, my-pod의 6000번 포트로 전달
kubectl exec my-pod -- ls / # 기존 파드에서 명령 실행(한 개 컨테이너 경우)
kubectl exec --stdin --tty my-pod -- /bin/sh # 실행 중인 파드로 대화형 셸 액세스(1 컨테이너 경우)
kubectl exec my-pod -c my-container -- ls / # 기존 파드에서 명령 실행(멀티-컨테이너 경우)
kubectl top pod POD_NAME --containers # 특정 파드와 해당 컨테이너에 대한 메트릭 표시
kubectl top pod POD_NAME --sort-by=cpu # 지정한 파드에 대한 메트릭을 표시하고 'cpu' 또는 'memory'별로 정렬
컨테이너로/컨테이너에서 파일과 디렉터리 복사
kubectl cp /tmp/foo_dir my-pod:/tmp/bar_dir # 로컬 디렉토리 /tmp/foo_dir 를 현재 네임스페이스의 my-pod 파드 안의 /tmp/bar_dir 로 복사
kubectl cp /tmp/foo my-pod:/tmp/bar -c my-container # 로컬 파일 /tmp/foo 를 my-pod 파드의 my-container 컨테이너 안의 /tmp/bar 로 복사
kubectl cp /tmp/foo my-namespace/my-pod:/tmp/bar # 로컬 파일 /tmp/foo 를 my-namespace 네임스페이스의 my-pod 파드 안의 /tmp/bar 로 복사
kubectl cp my-namespace/my-pod:/tmp/foo /tmp/bar # my-namespace 네임스페이스의 my-pod 파드 안의 파일 /tmp/foo 를 로컬의 /tmp/bar 로 복사
kubectl cp
명령을 사용하려면 컨테이너 이미지에 'tar' 바이너리가 포함되어 있어야 한다. 'tar'가 없으면, kubectl cp
는 실패할 것이다.
심볼릭 링크, 와일드카드 확장, 파일 모드 보존과 같은 고급 사용 사례에 대해서는 kubectl exec
를 고려해볼 수 있다.
tar cf - /tmp/foo | kubectl exec -i -n my-namespace my-pod -- tar xf - -C /tmp/bar # 로컬 파일 /tmp/foo 를 my-namespace 네임스페이스의 my-pod 파드 안의 /tmp/bar 로 복사
kubectl exec -n my-namespace my-pod -- tar cf - /tmp/foo | tar xf - -C /tmp/bar # my-namespace 네임스페이스의 my-pod 파드 안의 파일 /tmp/foo 를 로컬의 /tmp/bar 로 복사
디플로이먼트, 서비스와 상호 작용
kubectl logs deploy/my-deployment # 디플로이먼트에 대한 파드 로그 덤프 (단일-컨테이너 경우)
kubectl logs deploy/my-deployment -c my-container # 디플로이먼트에 대한 파드 로그 덤프 (멀티-컨테이너 경우)
kubectl port-forward svc/my-service 5000 # 로컬 머신의 5000번 포트를 리스닝하고, my-service의 동일한(5000번) 포트로 전달
kubectl port-forward svc/my-service 5000:my-service-port # 로컬 머신의 5000번 포트를 리스닝하고, my-service의 <my-service-port> 라는 이름을 가진 포트로 전달
kubectl port-forward deploy/my-deployment 5000:6000 # 로컬 머신의 5000번 포트를 리스닝하고, <my-deployment> 에 의해 생성된 파드의 6000번 포트로 전달
kubectl exec deploy/my-deployment -- ls # <my-deployment> 에 의해 생성된 첫번째 파드의 첫번째 컨테이너에 명령어 실행 (단일- 또는 다중-컨테이너 경우)
노드, 클러스터와 상호 작용
kubectl cordon my-node # my-node를 스케줄링할 수 없도록 표기
kubectl drain my-node # 유지 보수를 위해서 my-node를 준비 상태로 비움
kubectl uncordon my-node # my-node를 스케줄링할 수 있도록 표기
kubectl top node my-node # 주어진 노드에 대한 메트릭 표시
kubectl cluster-info # 마스터 및 서비스의 주소 표시
kubectl cluster-info dump # 현재 클러스터 상태를 stdout으로 덤프
kubectl cluster-info dump --output-directory=/path/to/cluster-state # 현재 클러스터 상태를 /path/to/cluster-state으로 덤프
# key와 effect가 있는 테인트(taint)가 이미 존재하면, 그 값이 지정된 대로 대체된다.
kubectl taint nodes foo dedicated=special-user:NoSchedule
리소스 타입
단축명, API 그룹과 함께 지원되는 모든 리소스 유형들, 그것들의 네임스페이스와 종류(Kind)를 나열:
kubectl api-resources
API 리소스를 탐색하기 위한 다른 작업:
kubectl api-resources --namespaced=true # 네임스페이스를 가지는 모든 리소스
kubectl api-resources --namespaced=false # 네임스페이스를 가지지 않는 모든 리소스
kubectl api-resources -o name # 모든 리소스의 단순한 (리소스 이름만) 출력
kubectl api-resources -o wide # 모든 리소스의 확장된 ("wide"로 알려진) 출력
kubectl api-resources --verbs=list,get # "list"와 "get"의 요청 동사를 지원하는 모든 리소스 출력
kubectl api-resources --api-group=extensions # "extensions" API 그룹의 모든 리소스
출력 형식 지정
특정 형식으로 터미널 창에 세부 사항을 출력하려면, 지원되는 kubectl
명령에 -o
(또는 --output
) 플래그를 추가한다.
출력 형식 | 세부 사항 |
---|---|
-o=custom-columns=<명세> |
쉼표로 구분된 사용자 정의 열 목록을 사용하여 테이블 출력 |
-o=custom-columns-file=<파일명> |
<파일명> 파일에서 사용자 정의 열 템플릿을 사용하여 테이블 출력 |
-o=json |
JSON 형식의 API 오브젝트 출력 |
-o=jsonpath=<템플릿> |
jsonpath 표현식에 정의된 필드 출력 |
-o=jsonpath-file=<파일명> |
<파일명> 파일에서 jsonpath 표현식에 정의된 필드 출력 |
-o=name |
리소스 명만 출력하고 그 외에는 출력하지 않음 |
-o=wide |
추가 정보가 포함된 일반-텍스트 형식으로 출력하고, 파드의 경우 노드 명이 포함 |
-o=yaml |
YAML 형식의 API 오브젝트 출력 |
-o=custom-columns
의 사용 예시:
# 클러스터에서 실행 중인 모든 이미지
kubectl get pods -A -o=custom-columns='DATA:spec.containers[*].image'
# `default` 네임스페이스의 모든 이미지를 파드별로 그룹지어 출력
kubectl get pods --namespace default --output=custom-columns="NAME:.metadata.name,IMAGE:.spec.containers[*].image"
# "k8s.gcr.io/coredns:1.6.2" 를 제외한 모든 이미지
kubectl get pods -A -o=custom-columns='DATA:spec.containers[?(@.image!="k8s.gcr.io/coredns:1.6.2")].image'
# 이름에 관계없이 메타데이터 아래의 모든 필드
kubectl get pods -A -o=custom-columns='DATA:metadata.*'
더 많은 예제는 kubectl 참조 문서를 참고한다.
Kubectl 출력 로그 상세 레벨(verbosity)과 디버깅
Kubectl 로그 상세 레벨(verbosity)은 -v
또는--v
플래그와 로그 레벨을 나타내는 정수로 제어된다. 일반적인 쿠버네티스 로깅 규칙과 관련 로그 레벨이 여기에 설명되어 있다.
로그 레벨 | 세부 사항 |
---|---|
--v=0 |
일반적으로 클러스터 운영자(operator)에게 항상 보여지게 하기에는 유용함. |
--v=1 |
자세한 정보를 원하지 않는 경우, 적절한 기본 로그 수준. |
--v=2 |
서비스와 시스템의 중요한 변화와 관련이있는 중요한 로그 메시지에 대한 유용한 정상 상태 정보. 이는 대부분의 시스템에서 권장되는 기본 로그 수준이다. |
--v=3 |
변경 사항에 대한 확장 정보. |
--v=4 |
디버그 수준 상세화. |
--v=5 |
트레이스 수준 상세화. |
--v=6 |
요청한 리소스를 표시. |
--v=7 |
HTTP 요청 헤더를 표시. |
--v=8 |
HTTP 요청 내용을 표시. |
--v=9 |
내용을 잘라 내지 않고 HTTP 요청 내용을 표시. |
다음 내용
-
kubectl 개요를 읽고 JsonPath에 대해 배워보자.
-
kubectl 옵션을 참고한다.
-
재사용 스크립트에서 kubectl 사용 방법을 이해하기 위해 kubectl 사용법을 참고한다.
-
더 많은 커뮤니티 kubectl 치트시트를 확인한다.
6 - 도커 사용자를 위한 kubectl
당신은 쿠버네티스 커맨드 라인 도구인 kubectl
을 사용하여 API 서버와 상호 작용할 수 있다. 만약 도커 커맨드 라인 도구에 익숙하다면 kubectl
을 사용하는 것은 간단하다. 다음 섹션에서는 도커의 하위 명령을 보여주고 kubectl
과 같은 명령어를 설명한다.
docker run
nginx 디플로이먼트(Deployment)를 실행하고 해당 디플로이먼트를 노출시키려면, kubectl create deployment을 참고한다. docker:
docker run -d --restart=always -e DOMAIN=cluster --name nginx-app -p 80:80 nginx
55c103fa129692154a7652490236fee9be47d70a8dd562281ae7d2f9a339a6db
docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
55c103fa1296 nginx "nginx -g 'daemon of…" 9 seconds ago Up 9 seconds 0.0.0.0:80->80/tcp nginx-app
kubectl:
# nginx 실행하는 파드를 시작한다
kubectl create deployment --image=nginx nginx-app
deployment.apps/nginx-app created
# nginx-app 에 env를 추가한다
kubectl set env deployment/nginx-app DOMAIN=cluster
deployment.apps/nginx-app env updated
kubectl
커맨드는 생성되거나 변경된 리소스의 유형과 이름을 출력하므로, 이를 후속 커맨드에 사용할 수 있다. 디플로이먼트가 생성된 후에는 새로운 서비스를 노출할 수 있다.
# 서비스를 통해 포트를 노출
kubectl expose deployment nginx-app --port=80 --name=nginx-http
service "nginx-http" exposed
kubectl을 사용하면, N개의 파드가 nginx를 실행하도록 디플로이먼트를 생성할 수 있다. 여기서 N은 스펙에 명시된 레플리카 수이며, 기본값은 1이다. 또한 파드의 레이블과 셀럭터를 사용하여 서비스를 생성할 수 있다. 자세한 내용은 클러스터 내 애플리케이션에 접근하기 위해 서비스 사용하기를 참고한다.
기본적으로 이미지는 docker run -d ...
와 비슷하게 백그라운드로 실행된다. 포그라운드로 실행하려면 kubectl run
을 이용하여 파드를 생성한다.
kubectl run [-i] [--tty] --attach <name> --image=<image>
docker run ...
과 달리 --attach
를 지정하면 표준 입력(stdin)
, 표준 출력(stdout)
및 표준 오류(stderr)
가 붙는다. 연결된(attached) 스트림을 제어할 수 없다(docker -a ...
).
해당 컨테이너에서 분리(detach)하려면 이스케이프 시퀀스(escape sequence) Ctrl+P를 입력한 다음 Ctrl+Q를 입력한다.
docker ps
현재 실행 중인 목록을 보기 위해서는 kubectl get을 참고한다.
docker:
docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
14636241935f ubuntu:16.04 "echo test" 5 seconds ago Exited (0) 5 seconds ago cocky_fermi
55c103fa1296 nginx "nginx -g 'daemon of…" About a minute ago Up About a minute 0.0.0.0:80->80/tcp nginx-app
kubectl:
kubectl get po
NAME READY STATUS RESTARTS AGE
nginx-app-8df569cb7-4gd89 1/1 Running 0 3m
ubuntu 0/1 Completed 0 20s
docker attach
이미 실행 중인 컨테이너에 연결하려면 kubectl attach를 참고한다.
docker:
docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
55c103fa1296 nginx "nginx -g 'daemon of…" 5 minutes ago Up 5 minutes 0.0.0.0:80->80/tcp nginx-app
docker attach 55c103fa1296
...
kubectl:
kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-app-5jyvm 1/1 Running 0 10m
kubectl attach -it nginx-app-5jyvm
...
컨테이너에서 분리하려면 이스케이프 시퀀스 Ctrl+P를 입력한 다음 Ctrl+Q를 입력한다.
docker exec
컨테이너에서 커맨드를 실행하려면 kubectl exec를 참고한다.
docker:
docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
55c103fa1296 nginx "nginx -g 'daemon of…" 6 minutes ago Up 6 minutes 0.0.0.0:80->80/tcp nginx-app
docker exec 55c103fa1296 cat /etc/hostname
55c103fa1296
kubectl:
kubectl get po
NAME READY STATUS RESTARTS AGE
nginx-app-5jyvm 1/1 Running 0 10m
kubectl exec nginx-app-5jyvm -- cat /etc/hostname
nginx-app-5jyvm
대화형 커맨드를 사용한다.
docker:
docker exec -ti 55c103fa1296 /bin/sh
# exit
kubectl:
kubectl exec -ti nginx-app-5jyvm -- /bin/sh
# exit
자세한 내용은 실행 중인 컨테이너의 셸 얻기를 참고한다.
docker logs
실행 중인 프로세스의 표준 입력(stdout)/표준 오류(stderr)를 수행하려면 kubectl logs를 참고한다.
docker:
docker logs -f a9e
192.168.9.1 - - [14/Jul/2015:01:04:02 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.35.0" "-"
192.168.9.1 - - [14/Jul/2015:01:04:03 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.35.0" "-"
kubectl:
kubectl logs -f nginx-app-zibvs
10.240.63.110 - - [14/Jul/2015:01:09:01 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.26.0" "-"
10.240.63.110 - - [14/Jul/2015:01:09:02 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.26.0" "-"
파드와 컨테이너에는 근소한 차이가 있다. 기본적으로 파드는 프로세스가 종료되어도 종료되지 않는다. 대신 파드가 프로세스를 다시 시작한다. 이는 도커의 실행 옵션인 --restart=always
와 유사하지만, 한 가지 큰 차이점이 있다. 도커에서는 프로세스의 각 호출에 대한 출력이 연결되지만, 쿠버네티스의 경우 각 호출은 별개다. 쿠버네티스에서 이전 실행의 출력 내용을 보려면 다음을 수행한다.
kubectl logs --previous nginx-app-zibvs
10.240.63.110 - - [14/Jul/2015:01:09:01 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.26.0" "-"
10.240.63.110 - - [14/Jul/2015:01:09:02 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.26.0" "-"
자세한 정보는 로깅 아키텍처를 참고한다.
docker stop 과 docker rm
실행 중인 프로세스를 중지하고 삭제하려면 kubectl delete을 참고한다.
docker:
docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
a9ec34d98787 nginx "nginx -g 'daemon of" 22 hours ago Up 22 hours 0.0.0.0:80->80/tcp, 443/tcp nginx-app
docker stop a9ec34d98787
a9ec34d98787
docker rm a9ec34d98787
a9ec34d98787
kubectl:
kubectl get deployment nginx-app
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-app 1/1 1 1 2m
kubectl get po -l app=nginx-app
NAME READY STATUS RESTARTS AGE
nginx-app-2883164633-aklf7 1/1 Running 0 2m
kubectl delete deployment nginx-app
deployment "nginx-app" deleted
kubectl get po -l app=nginx-app
# 아무것도 반환하지 않는다
docker login
kubectl은 docker login
와 직접적인 유사점은 없다. 프라이빗 레지스트리와 함께 쿠버네티스를 사용하려면 프라이빗 레지스트리 사용을 참고한다.
docker version
클라이언트와 서버의 버전을 가져오려면 kubectl version을 참고한다.
docker:
docker version
Client version: 1.7.0
Client API version: 1.19
Go version (client): go1.4.2
Git commit (client): 0baf609
OS/Arch (client): linux/amd64
Server version: 1.7.0
Server API version: 1.19
Go version (server): go1.4.2
Git commit (server): 0baf609
OS/Arch (server): linux/amd64
kubectl:
kubectl version
Client Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.9+a3d1dfa6f4335", GitCommit:"9b77fed11a9843ce3780f70dd251e92901c43072", GitTreeState:"dirty", BuildDate:"2017-08-29T20:32:58Z", OpenPaasKubernetesVersion:"v1.03.02", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.9+a3d1dfa6f4335", GitCommit:"9b77fed11a9843ce3780f70dd251e92901c43072", GitTreeState:"dirty", BuildDate:"2017-08-29T20:32:58Z", OpenPaasKubernetesVersion:"v1.03.02", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"}
docker info
환경 및 설정에 대한 자세한 정보는 kubectl cluster-info를 참고한다.
docker:
docker info
Containers: 40
Images: 168
Storage Driver: aufs
Root Dir: /usr/local/google/docker/aufs
Backing Filesystem: extfs
Dirs: 248
Dirperm1 Supported: false
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.13.0-53-generic
Operating System: Ubuntu 14.04.2 LTS
CPUs: 12
Total Memory: 31.32 GiB
Name: k8s-is-fun.mtv.corp.google.com
ID: ADUV:GCYR:B3VJ:HMPO:LNPQ:KD5S:YKFQ:76VN:IANZ:7TFV:ZBF4:BYJO
WARNING: No swap limit support
kubectl:
kubectl cluster-info
Kubernetes master is running at https://203.0.113.141
KubeDNS is running at https://203.0.113.141/api/v1/namespaces/kube-system/services/kube-dns/proxy
kubernetes-dashboard is running at https://203.0.113.141/api/v1/namespaces/kube-system/services/kubernetes-dashboard/proxy
Grafana is running at https://203.0.113.141/api/v1/namespaces/kube-system/services/monitoring-grafana/proxy
Heapster is running at https://203.0.113.141/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy
InfluxDB is running at https://203.0.113.141/api/v1/namespaces/kube-system/services/monitoring-influxdb/proxy