Kubectl

NOWNIZ·2023년 1월 26일
0

Blah Blah

목록 보기
8/9

In Official docs

Kubectl : 쿠버네티스 클러스터를 제어하기 위한 커맨드 라인 도구 (CLI).

kubectl의 config 파일은 $HOME/.kube 에 위치하고 있다.

  • KUBECONFIG 환경 변수를 설정하거나 --kubeconfig 플래그 옵션을 통하여 다른 kubeconfig 파일을 지정할 수 있다.

구문

kubectl [command] [TYPE] [NAME] [flags]

  • command : 하나 이상의 리소스에서 수행하려는 동작을 지정한다.
    • ex) create, get, describe, delete
명령어구문설명
alphakubectl alpha SUBCOMMAND [flags]쿠버네티스 클러스터에서 기본적으로 활성화되어 있지 않은 알파 기능의 사용할 수 있는 명령을 나열한다.
annotatekubectl annotate (-f FILENAMETYPE NAME
api-resourceskubectl api-resources [flags]사용 가능한 API 리소스를 나열한다.
api-versionskubectl api-versions [flags]사용 가능한 API 버전을 나열한다.
applykubectl apply -f FILENAME [flags]파일이나 표준입력(stdin)으로부터 리소스에 구성 변경 사항을 적용한다.
attachkubectl attach POD -c CONTAINER [-i][-t] [flags]실행 중인 컨테이너에 연결하여 출력 스트림을 보거나 표준입력을 통해 컨테이너와 상호 작용한다.
authkubectl auth [flags][options]승인을 검사한다.
autoscalekubectl autoscale (-f FILENAMETYPE NAME
certificatekubectl certificate SUBCOMMAND [options]인증서 리소스를 수정한다.
cluster-infokubectl cluster-info [flags]클러스터의 마스터와 서비스에 대한 엔드포인트 정보를 표시한다.
completionkubectl completion SHELL [options]지정된 셸(bash 또는 zsh)에 대한 셸 완성 코드를 출력한다.
configkubectl config SUBCOMMAND [flags]kubeconfig 파일을 수정한다. 세부 사항은 개별 하위 명령을 참고한다.
convertkubectl convert -f FILENAME [options]다른 API 버전 간에 구성 파일을 변환한다. YAML 및 JSON 형식이 모두 허용된다. 참고 - kubectl-convert 플러그인을 설치해야 한다.
cordonkubectl cordon NODE [options]노드를 스케줄 불가능(unschedulable)으로 표시한다.
cpkubectl cp [options]컨테이너에서 그리고 컨테이너로 파일 및 디렉터리를 복사한다.
createkubectl create -f FILENAME [flags]파일이나 표준입력에서 하나 이상의 리소스를 생성한다.
deletekubectl delete (-f FILENAMETYPE [NAME
describekubectl describe (-f FILENAMETYPE [NAME_PREFIX
diffkubectl diff -f FILENAME [flags]라이브 구성에 대해 파일이나 표준입력의 차이점을 출력한다.
drainkubectl drain NODE [options]유지 보수를 준비 중인 노드를 드레인한다.
editkubectl edit (-f FILENAMETYPE NAME
execkubectl exec POD [-c CONTAINER][-i] [-t][flags] [-- COMMAND [args...]]파드의 컨테이너에 대해 명령을 실행한다.
explainkubectl explain [--recursive=false][flags]파드, 노드, 서비스 등의 다양한 리소스에 대한 문서를 출력한다.
exposekubectl expose (-f FILENAMETYPE NAME
getkubectl get (-f FILENAMETYPE [NAME
kustomizekubectl kustomize [flags][options]kustomization.yaml 파일의 지시 사항에서 생성된 API 리소스 집합을 나열한다. 인수는 파일을 포함하는 디렉터리의 경로이거나, 리포지터리 루트와 관련하여 경로 접미사가 동일한 git 리포지터리 URL이어야 한다.
labelkubectl label (-f FILENAMETYPE NAME
logskubectl logs POD [-c CONTAINER][--follow] [flags]파드의 컨테이너에 대한 로그를 출력한다.
optionskubectl options모든 명령에 적용되는 전역 커맨드 라인 옵션을 나열한다.
patchkubectl patch (-f FILENAMETYPE NAME
pluginkubectl plugin [flags][options]플러그인과 상호 작용하기 위한 유틸리티를 제공한다.
port-forwardkubectl port-forward POD [LOCAL_PORT:]REMOTE_PORT [...[LOCAL_PORT_N:]REMOTE_PORT_N][flags]하나 이상의 로컬 포트를 파드로 전달한다.
proxykubectl proxy [--port=PORT][--www=static-dir] [--www-prefix=prefix][--api-prefix=prefix] [flags]쿠버네티스 API 서버에 프록시를 실행한다.
replacekubectl replace -f FILENAME파일 또는 표준입력에서 리소스를 교체한다.
rolloutkubectl rollout SUBCOMMAND [options]리소스의 롤아웃을 관리한다. 유효한 리소스 타입에는 디플로이먼트(deployment), 데몬셋(daemonset)과 스테이트풀셋(statefulset)이 포함된다.
runkubectl run NAME --image=image [--env="key=value"][--port=port] [--dry-run=serverclient
scalekubectl scale (-f FILENAMETYPE NAME
setkubectl set SUBCOMMAND [options]애플리케이션 리소스를 구성한다.
taintkubectl taint NODE NAME KEY_1=VAL_1:TAINT_EFFECT_1 ... KEY_N=VAL_N:TAINT_EFFECT_N [options]하나 이상의 노드에서 테인트(taint)를 업데이트한다.
topkubectl top [flags][options]리소스(CPU/메모리/스토리지) 사용량을 표시한다.
uncordonkubectl uncordon NODE [options]노드를 스케줄 가능(schedulable)으로 표시한다.
versionkubectl version [--client][flags]클라이언트와 서버에서 실행 중인 쿠버네티스 버전을 표시한다.
waitkubectl wait ([-f FILENAME]resource.group/resource.name
  • TYPE : 리소스 타입을 지정한다. 리소스 탕비은 대소문자를 구분하지 않으며 단수형, 복수형 또는 약어 형식을 지정할 수 있다.
kubectl get pod pod1
kubectl get pods pod1
kubectl get po pod1
NAMESHORTNAMESAPIGROUPNAMESPACEDKIND
bindingstrueBinding
componentstatusescsfalseComponentStatus
configmapscmtrueConfigMap
endpointseptrueEndpoints
eventsevtrueEvent
limitrangeslimitstrueLimitRange
namespacesnsfalseNamespace
nodesnofalseNode
persistentvolumeclaimspvctruePersistentVolumeClaim
persistentvolumespvfalsePersistentVolume
podspotruePod
podtemplatestruePodTemplate
replicationcontrollersrctrueReplicationController
resourcequotasquotatrueResourceQuota
secretstrueSecret
serviceaccountssatrueServiceAccount
servicessvctrueService
mutatingwebhookconfigurationshttp://admissionregistration.k8s.io/falseMutatingWebhookConfiguration
validatingwebhookconfigurationshttp://admissionregistration.k8s.io/falseValidatingWebhookConfiguration
customresourcedefinitionscrd,crdshttp://apiextensions.k8s.io/falseCustomResourceDefinition
apiserviceshttp://apiregistration.k8s.io/falseAPIService
controllerrevisionsappstrueControllerRevision
daemonsetsdsappstrueDaemonSet
deploymentsdeployappstrueDeployment
replicasetsrsappstrueReplicaSet
statefulsetsstsappstrueStatefulSet
tokenreviewshttp://authentication.k8s.io/falseTokenReview
localsubjectaccessreviewshttp://authorization.k8s.io/trueLocalSubjectAccessReview
selfsubjectaccessreviewshttp://authorization.k8s.io/falseSelfSubjectAccessReview
selfsubjectrulesreviewshttp://authorization.k8s.io/falseSelfSubjectRulesReview
subjectaccessreviewshttp://authorization.k8s.io/falseSubjectAccessReview
horizontalpodautoscalershpaautoscalingtrueHorizontalPodAutoscaler
cronjobscjbatchtrueCronJob
jobsbatchtrueJob
certificatesigningrequestscsrhttp://certificates.k8s.io/falseCertificateSigningRequest
leaseshttp://coordination.k8s.io/trueLease
endpointsliceshttp://discovery.k8s.io/trueEndpointSlice
eventsevhttp://events.k8s.io/trueEvent
ingressesingextensionstrueIngress
flowschemashttp://flowcontrol.apiserver.k8s.io/falseFlowSchema
prioritylevelconfigurationshttp://flowcontrol.apiserver.k8s.io/falsePriorityLevelConfiguration
ingressclasseshttp://networking.k8s.io/falseIngressClass
ingressesinghttp://networking.k8s.io/trueIngress
networkpoliciesnetpolhttp://networking.k8s.io/trueNetworkPolicy
runtimeclasseshttp://node.k8s.io/falseRuntimeClass
poddisruptionbudgetspdbpolicytruePodDisruptionBudget
podsecuritypoliciespsppolicyfalsePodSecurityPolicy
clusterrolebindingshttp://rbac.authorization.k8s.io/falseClusterRoleBinding
clusterroleshttp://rbac.authorization.k8s.io/falseClusterRole
rolebindingshttp://rbac.authorization.k8s.io/trueRoleBinding
roleshttp://rbac.authorization.k8s.io/trueRole
priorityclassespchttp://scheduling.k8s.io/falsePriorityClass
csidrivershttp://storage.k8s.io/falseCSIDriver
csinodeshttp://storage.k8s.io/falseCSINode
storageclassesschttp://storage.k8s.io/falseStorageClass
volumeattachmentshttp://storage.k8s.io/falseVolumeAttachment
  • NAME : 리소스 이름을 지정한다. 이름은 대소문자를 구분한다. 이름을 생략하면, 모든 리소스에 대한 세부 사항이 표시된다.
    • ex) kubectl get pods
    • 여러 리소스에 대한 작업을 수행할 때, 타입 및 이름별로 각 리소스를 지정하거나 하나 이상의 파일을 지정할 수 있다.
      • 리소스가 모두 동일한 타입인 경우 리소스를 그룹화하려면 다음을 사용한다.
        • ex) kubectl get pod example-pod1 example-pod2 …
      • 여러 리소스 타입을 개별적으로 지정하려면 다음을 사용한다.
        • ex) kubectl get pod/example-pod1 replicationcontroller/example-rc1
      • 하나 이상의 파일로 리소스를 지정하려면 다음을 사용한다.
        • ex) kubectl get -f ./pod.yaml -f ./pod2.yaml …
  • flags : 선택적 플래그 옵션을 지정한다.

여기까진 Docs의 Reference인데…


그렇다면 작동 원리는 무엇일까??

기술적인 관점에서 kubectl은 kubernetes API용 클라이언트이다.

kubernetes API는 HTTP REST API이다. 이 API는 Kubernetes의 실 사용자 인터페이스이며, Kubernetes는 이 API를 통해 완전히 제어된다. 결과적으로 kubectl의 주요 작업은 Kubernetes API에 대한 HTTP 요청을 수행하는 것이다.

Kubernetes는 완전한 리소스 중심 시스템이다. 즉, K8S는 리소스의 내부 상태를 유지하고 모든 K8S 작업은 이러한 리소스에 대한 CRUD 작업이다.

예를 들어, K8S에서 ReplicaSet을 생성한다고 가정했을 때, 다음과 같은 명령을 실행한다.

$ kubectl create -f replicaset.yaml

이 명령어를 실행했을 때, K8S는 어떻게 Create ReplicaSet 작업을 실행할까? 이 작업에 대한 특정 API의 엔드포인트는 다음과 같다.

POST /apis/apps/v1/namespaces/{namespace}/replicasets

따라서, 위의 명령을 실행하면 kubectl은 위의 API 엔드포인트에 HTTP POST 요청을 한다. replicaset.yaml 파일에서 제공되는 ReplicaSet 정의는 Request Body에 전달된다.

이것이 kubectl이 K8S클러스터와 상호 작용하는 모든 명령에 대해 작동하는 방식이다.

그렇다면 이 API를 받았을 때, K8S 내부에서는 어떤 프로세스로 동작하게 될까?

위와 같은 예시와 같이 kubectl create -f replicaset.yaml을 방금 실행했다고 가정해보자.

그 다음 API 서버는 저장소 백엔드 (etcd)에 ReplicaSet 리소스 정의를 저장한다.

이렇게 하면 ReplicaSet 리소스의 생성, 업데이트 및 삭제를 감시하는 Controller Manager의 ReplicaSet Controller가 트리거된다.

ReplicaSet 컨트롤러는 ReplicaSet의 각 복제본에 대한 Pod 정의를 생성하고 이를 백엔드 스토리지 (etcd)에 저장한다.

Worker Node에 아직 할당되지 않은 Pod를 감시하는 Scheduler를 트리거한다.

Scheduler는 각 파드에 적합한 Worker Node를 선택하고 이 정보를 백엔드 스토리지 (etcd) Pod 정의에 추가한다.

그 뒤, Pod가 예약된 Worker Node에서 Kubelet을 트리고 하고 Worker node에 예약된 Pod를 감시한다.

Kubelet은 etcd에서 Pod 정의를 읽고 컨테이너 런타임 (Docker)에 Worker Node에서 컨테이너를 실행하도록 지시한다.

이것이 kubectl을 통한 전반적인 K8S로의 명령 구조이다.

profile
DevOps & Cloud Engineering

0개의 댓글