목차

1. Part.1
   1. kubectl get
   2. kubectl describe
   3. kubectl logs
   4. kubectl top
   5. kubectl version
2. Part.2
   1. kubectl explain
   2. kubectl cluster-info
   3. kubectl auth can-i
   4. kubectl api-resources

kubectl explain

kubectl explain 명령어는 Kubernetes 리소스나 API 개체의 필드와 값을 설명하는 명령어입니다. 이 명령어를 사용하면, 리소스나 API 개체의 필드와 값을 이해하는 데 도움이 됩니다.

1. 기본적인 사용 방법은 다음과 같습니다.
   kubectl explain [리소스 종류]
   
   예시: kubectl explain pod
   Pod 리소스의 필드와 값을 확인할 수 있습니다.
   
   
2. 옵션
   
   • --recursive, -r: 모든 참조된 리소스의 필드와 값을 출력합니다.
     
     예시: kubectl explain pod --recursive 
     (Pod 리소스와 관련된 모든 참조된 리소스의 필드와 값을 출력합니다.)
     
     
   • --api-version: API 버전을 지정합니다.
     
     예시: kubectl explain pod --api-version=v1
      (v1 버전의 Pod 리소스의 필드와 값을 출력합니다.)
     
     
   • --show-defaults: 기본값을 포함하여 출력합니다.
     
     예시: kubectl explain pod --show-defaults 
     (Pod 리소스의 필드와 값을 기본값과 함께 출력합니다.)

kubectl cluster-info

kubectl cluster-info 명령어는 Kubernetes 클러스터에 대한 정보를 출력하는 명령어입니다. 이 명령어를 사용하면, 클러스터에 대한 정보를 확인할 수 있습니다.

1. 기본 구조
   kubectl cluster-info
   Kubernetes 클러스터의 정보가 출력됩니다. 이 명령어는 클러스터의 API 서버와 DNS 서비스의 IP 주소, 포트, 클러스터의 CA 인증서, API 서버의 버전 정보 등을 포함합니다.
   
   
2. 옵션
   
   • --context: 사용할 컨텍스트를 지정합니다.
     
     예시: kubectl cluster-info --context=my-context 
     (my-context 컨텍스트를 사용하여 클러스터 정보를 출력합니다.)
     
     
   • --namespace: 리소스가 포함된 네임스페이스를 지정합니다.
     
     예시: kubectl cluster-info --namespace=my-namespace 
     (my-namespace 네임스페이스에 대한 클러스터 정보를 출력합니다.)

kubectl auth can-i 

kubectl auth can-i 명령어는 Kubernetes 리소스에 대한 사용 권한을 확인하는 명령어입니다. 이 명령어를 사용하면, 특정 사용자가 리소스에 대한 액션을 수행할 수 있는지 여부를 확인할 수 있습니다.

1. 기본 구조
   kubectl auth can-i [액션] [리소스 종류] [--namespace namespace] [--subresource subresource] [--list]
   
   예시: kubectl auth can-i get pods
   현재 인증된 사용자가 파드를 가져올 수 있는지 여부를 확인할 수 있습니다.
   
   
2. 옵션
   
   • --namespace: 네임스페이스를 지정합니다.
     
     예시: kubectl auth can-i get pods --namespace=my-namespace 
     (my-namespace 네임스페이스 내 파드를 가져올 수 있는지 여부를 확인합니다.)
     
     
   • --subresource: 서브리소스를 지정합니다.
     
     예시: kubectl auth can-i get events --subresource=watch 
     (이벤트의 watch 서브리소스를 가져올 수 있는지 여부를 확인합니다.)
     
     
   • --list: 리소스 목록을 출력합니다.
     
     예시: kubectl auth can-i list pods --list
      (현재 사용자가 모든 파드를 가져올 수 있는지 여부와 함께 파드 목록을 출력합니다.)

kubectl api-resources

kubectl api-resources 명령어는 Kubernetes API에 정의된 리소스 종류를 출력하는 명령어입니다. 이 명령어를 사용하면, 클러스터 내에서 사용 가능한 리소스 종류를 확인할 수 있습니다.

1. 기본 구조
   kubectl api-resources
   Kubernetes API에 정의된 모든 리소스 종류와 해당 리소스의 별칭, 리소스 유형 등의 정보를 출력합니다.
   
   
2. 옵션
   
   • --namespaced: 네임스페이스를 사용하는 리소스만 출력합니다.
     
     예시: kubectl api-resources --namespaced
      (네임스페이스를 사용하는 리소스 종류만 출력합니다.)
     
     
   • --verbs: 지정한 액션을 수행할 수 있는 리소스만 출력합니다.
     
     예시: kubectl api-resources --verbs=get,delete 
     (get과 delete 액션을 수행할 수 있는 리소스 종류만 출력합니다.)
     
     
   • --api-group: 지정한 API 그룹에 속한 리소스만 출력합니다.
     
     예시: kubectl api-resources --api-group=apps
      (apps API 그룹에 속한 리소스 종류만 출력합니다.)

목차

1. Part.1
   1. kubectl get
   2. kubectl describe
   3. kubectl logs
   4. kubectl top
   5. kubectl version
2. Part.2
   1. kubectl explain
   2. kubectl cluster-info
   3. kubectl auth can-i
   4. kubectl api-resources

kubectl get

kubectl get 명령어는 쿠버네티스(Kubernetes)에서 리소스를 조회하는 데 사용됩니다. 이 명령어에는 다양한 옵션이 제공됩니다. 각 옵션에 대한 설명과 함께 예시를 들어 설명하겠습니다.

1. 기본 구조
   kubectl get [리소스 종류] [옵션]
2. kubectl get 명령어로 조회 가능한 일부 리소스 유형
   
   • Pod (클러스터 내의 실행 중인 모든 Pod 조회)
   • Service
   • Deployment
   • ConfigMap
   • Secret
   • Node
   • Namespace
   • PersistentVolume
   • StorageClass
   • Ingress
3. 옵션
   
   • --all-namespaces 또는 -A: 모든 네임스페이스에서 리소스를 조회합니다.
     예시: kubectl get pods --all-namespaces
     
     
   • --selector 또는 -l: 라벨 셀렉터를 사용하여 특정 리소스를 조회합니다. 
     예시: kubectl get pods -l app=myapp
     
     
   • --output 또는 -o: 출력 형식을 지정합니다. 예를 들어, "-o json" 명령은 JSON 형식으로 출력합니다.
      예시: kubectl get pods -o wide
     
     
   • --watch 또는 -w: 리소스 변경 사항을 실시간으로 모니터링합니다. 
     예시: kubectl get pods -w
     
     
   • --sort-by: 조회 결과를 정렬합니다. 예를 들어, "--sort-by=.metadata.creationTimestamp" 명령은 생성된 시간에 따라 정렬합니다.
      예시: kubectl get pods --sort-by=.status.phase
     
     
   • --field-selector: 필드 셀렉터를 사용하여 특정 필드의 값을 기준으로 리소스를 조회합니다. 
     예시: kubectl get pods --field-selector=status.phase=Running
     
     
   • --show-labels: 리소스에 대한 라벨 정보를 표시합니다. 
     예시: kubectl get pods --show-labels
     
     
   • --no-headers: 표 헤더를 표시하지 않습니다. 
     예시: kubectl get pods --no-headers
     
     
   • --export: 출력 결과에서 불필요한 정보를 제거합니다.
     예시: kubectl get pod my-pod -o yaml --export > my-pod.yaml
     ("my-pod" 이름을 가진 파드의 YAML 파일을 생성합니다. 이 때 --export 옵션을 사용하면 출력 결과에서 상태 및 메타데이터와 같은 불필요한 정보가 제거됩니다.)
     
     
   • --field-selector와 함께 사용할 수 있는 필드는 다양합니다. 예를 들어, "status.phase" 필드는 파드의 실행 상태를 나타내며, "metadata.name" 필드는 파드의 이름을 나타냅니다.
     
     
   • --show-kind: 조회 결과에 리소스 유형을 표시합니다.
     예시: kubectl get pods --show-kind
     
     
   • --ignore-not-found: 조회 결과가 없는 경우 에러를 발생시키지 않고 정상적으로 종료합니다.
      예시: kubectl get pods my-pod --ignore-not-found
     
     
   • --timeout: 조회 시간 제한을 설정합니다. 예를 들어, "--timeout=5s" 명령은 5초 동안 조회를 시도합니다. 
     예시: kubectl get pods --timeout=10s
     
     
   • --selector와 함께 사용할 수 있는 라벨 셀렉터의 사용 예시는 다음과 같습니다.
     
     • kubectl get pods -l app=myapp
       "app=myapp" 라벨을 가진 파드를 조회합니다.
       
       
     • kubectl get pods -l app!=myapp
       "app" 라벨이 "myapp"이 아닌 파드를 조회합니다.
       
       
     • kubectl get pods -l 'app in (myapp, yourapp)'
       "app" 라벨이 "myapp" 또는 "yourapp"인 파드를 조회합니다.
       
       
     • kubectl get pods -l 'app notin (myapp, yourapp)'
       "app" 라벨이 "myapp" 또는 "yourapp"이 아닌 파드를 조회합니다.

kubectl describe

kubectl describe 명령어는 Kubernetes 리소스의 상세 정보를 출력하는 명령어입니다. 이 명령어를 사용하면, 특정 리소스에 대한 자세한 정보를 확인할 수 있습니다.

1. 기본 구조
   kubectl describe [리소스 종류] [리소스 이름]
   
   예시: kubectl describe pod my-pod
   my-pod 이름의 파드 리소스에 대한 자세한 정보를 출력할 수 있습니다.
   
   
2. 옵션
   
   • --namespace: 리소스가 포함된 네임스페이스를 지정합니다.
     
     예시: kubectl describe pod my-pod --namespace my-namespace 
     (my-namespace 네임스페이스에 속한 my-pod 이름의 파드 리소스에 대한 자세한 정보를 출력합니다.)
     
     
   • --show-events: 리소스의 이벤트를 출력합니다.
     
     예시: kubectl describe pod my-pod --show-events
      (my-pod 이름의 파드 리소스에 대한 자세한 정보와 해당 리소스의 이벤트를 함께 출력합니다.)
     
     
   • --export: YAML 형식으로 출력합니다.
     
     예시: kubectl describe pod my-pod --export 
     (my-pod 이름의 파드 리소스에 대한 자세한 정보를 YAML 형식으로 출력합니다.)
     
     
   • --recursive: 서브리소스의 정보도 출력합니다.
     
     예시: kubectl describe deployment my-deployment --recursive
      (my-deployment 이름의 디플로이먼트 리소스에 대한 자세한 정보와 해당 디플로이먼트 리소스에 포함된 파드 리소스의 자세한 정보도 함께 출력합니다.)

kubectl logs

kubectl logs 명령어는 Kubernetes 파드 내부에서 실행 중인 컨테이너의 로그를 출력하는 명령어입니다. 이 명령어를 사용하면, 파드 내부에서 실행 중인 컨테이너의 로그를 실시간으로 확인하거나 파일로 저장할 수 있습니다.

1. 기본 구조
   kubectl logs [파드 이름] [컨테이너 이름]
   
   예시: kubectl logs my-pod my-container
   my-pod 이름의 파드 내부에서 my-container 이름의 컨테이너의 로그를 출력할 수 있습니다.
   
   
2. 옵션
   
   • --namespace: 파드가 포함된 네임스페이스를 지정합니다.
     
     예시: kubectl logs my-pod -n my-namespace my-container
      (my-namespace 네임스페이스에 속한 my-pod 이름의 파드 내부에서 my-container 이름의 컨테이너의 로그를 출력합니다.)
     
     
   • --follow, -f: 로그를 실시간으로 출력합니다.
     
     예시: kubectl logs my-pod my-container -f 
     (my-pod 이름의 파드 내부에서 my-container 이름의 컨테이너의 로그를 실시간으로 출력합니다.)
     
     
   • --tail: 출력할 로그 라인 수를 지정합니다.
     
     예시: kubectl logs my-pod my-container --tail=50 
     (my-pod 이름의 파드 내부에서 my-container 이름의 컨테이너의 로그를 최근 50개 라인만 출력합니다.)
     
     
   • --since: 출력할 로그의 시작 시간을 지정합니다.
     
     예시: kubectl logs my-pod my-container --since=1h
      (my-pod 이름의 파드 내부에서 my-container 이름의 컨테이너에서 1시간 이전부터 출력할 로그를 선택합니다.)

kubectl top

kubectl top 명령어는 Kubernetes 클러스터의 리소스 사용량을 확인하는 명령어입니다. 이 명령어를 사용하면, 노드나 파드 등의 리소스 사용량을 확인할 수 있습니다.

1. 기본 구조
   kubectl top [리소스 종류] [리소스 이름]
   
   예시: kubectl top pods
   클러스터 내 모든 파드의 리소스 사용량을 확인할 수 있습니다.
   
   예시2: kubectl top nodes
   클러스터 내 모든 노드의 리소스 사용량을 확인할 수 있습니다.
   
   
2. 옵션
   
   • --containers: 컨테이너 단위의 리소스 사용량을 확인합니다.
     
     예시: kubectl top pods --containers 
     (모든 파드의 컨테이너 단위의 리소스 사용량을 확인합니다.)
     
     
   • --heapster-namespace: Heapster의 네임스페이스를 지정합니다.
     
     예시: kubectl top pods --heapster-namespace=kube-system
      (Heapster가 설치된 kube-system 네임스페이스에 대한 파드의 리소스 사용량을 확인합니다.)

kubectl version

kubectl version 명령어는 Kubernetes API 서버와 클라이언트의 버전 정보를 확인하는 명령어입니다. 이 명령어를 사용하면, Kubernetes 클러스터의 버전 정보와 현재 사용 중인 kubectl 명령어의 버전 정보를 확인할 수 있습니다.

1. 기본 구조
   kubectl version
   클러스터의 버전 정보와 kubectl 명령어의 버전 정보가 출력됩니다.
   
   
2. 옵션
   
   • --short: 간략한 버전 정보를 출력합니다.
     
     예시: kubectl version --short 
     (kubectl 명령어와 클러스터의 버전 정보를 간략하게 출력합니다.)
     
     
   • --client: 클라이언트의 버전 정보만 출력합니다.
     
     예시: kubectl version --client 
     (kubectl 명령어의 버전 정보만 출력합니다.)
     
     
   • --server: 서버의 버전 정보만 출력합니다.
     
     예시: kubectl version --server
      (클러스터의 API 서버 버전 정보만 출력합니다.)

목차

1. 수정 관련 명령어
   1. kubectl scale
   2. kubectl patch
   3. kubectl edit
   4. kubectl label 
   5. kubectl annotate
2. 컨테이너에서 명령어 실행
   • kubectl exec
3. 대기 명령어
   • kubectl wait

수정 관련 명령어

kubectl scale

kubectl scale 명령어는 Kubernetes에서 디플로이먼트, 레플리카셋 등의 리소스의 replica 수를 조정할 때 사용하는 명령어입니다. replica 수를 늘리거나 줄이면서 시스템의 부하를 조절할 수 있습니다.

1. 기본 구조
   kubectl scale deployment [디플로이먼트 이름] --replicas=[수정할 replica 수]
   
   예시: kubectl scale deployment my-deployment --replicas=3
   (my-deployment 이름을 가진 디플로이먼트의 replica 수를 3개로 조정합니다.)
   
   
2. 옵션
   
   • --current-replicas: 현재 replica 수를 지정합니다. 이 값을 지정하면 --replicas 옵션으로 지정한 값과 함께 replica 수를 변경합니다.
     
     예시: kubectl scale deployment my-deployment --current-replicas=1 --replicas=3 
     (현재 1개의 replica가 있는 my-deployment 이름을 가진 디플로이먼트의 replica 수를 3개로 조정합니다.)
     
     
   • --resource-version: 리소스 버전을 지정합니다.
     
     예시: kubectl scale deployment my-deployment --replicas=3 --resource-version=4 
     (my-deployment 이름을 가진 디플로이먼트의 replica 수를 3개로 조정하면서, 리소스 버전을 4로 지정합니다.)
     
     
   • -n, --namespace: 리소스가 위치한 네임스페이스를 지정합니다.
     
     예시: kubectl scale deployment my-deployment --replicas=3 -n my-namespace
      (my-deployment 이름을 가진 디플로이먼트의 replica 수를 3개로 조정하면서, my-namespace 네임스페이스에 위치한 리소스를 조정합니다.)
     
     
   • --timeout: replica 수를 조정할 때, 타임아웃을 설정합니다.
     
     예시: kubectl scale deployment my-deployment --replicas=3 --timeout=60s 
     (my-deployment 이름을 가진 디플로이먼트의 replica 수를 3개로 조정하면서, 타임아웃을 60초로 설정합니다.)
     
     
   • --wait: replica 수를 조정한 후 변경이 완료될 때까지 대기합니다.
     예시: kubectl scale deployment my-deployment --replicas=3 --wait
     (my-deployment 이름을 가진 디플로이먼트의 replica 수를 3개로 조정하면서, 변경이 완료될 때까지 대기합니다.)

kubectl patch

kubectl patch 명령어는 Kubernetes 리소스의 일부를 수정하는 명령어입니다. 이 명령어를 사용하면, 리소스의 일부 값을 변경하거나 추가할 수 있습니다.

1. 기본 구조
   kubectl patch [리소스 종류] [리소스 이름] [수정할 필드]=[새 값]
   
   예시: kubectl patch deployment my-deployment -p '{"spec":{"replicas":3}}'
   ( my-deployment 이름의 배포의 레플리카 수를 3으로 변경할 수 있습니다.)
   
   
2. 옵션
   
   • -p, --patch: JSON 포맷으로 수정 내용을 지정합니다.
     
     예시: kubectl patch deployment my-deployment -p '{"spec":{"replicas":3}}' 
     (my-deployment 이름의 배포의 레플리카 수를 3으로 변경합니다.)
     
     
   • --type: 수정 내용의 포맷을 지정합니다. json, merge, strategic 중 하나를 지정할 수 있습니다. 기본값은 strategic입니다.
     
     예시: kubectl patch deployment my-deployment --type=json -p '[{"op":"replace","path":"/spec/replicas","value":3}]'
     (my-deployment 이름의 배포의 레플리카 수를 3으로 변경합니다. --type=json 옵션을 사용하여 JSON 포맷으로 수정 내용을 지정합니다.)

kubectl edit

kubectl edit 명령어는 Kubernetes 리소스의 구성을 수정하는 명령어입니다. 이 명령어를 사용하면, 기존 리소스의 YAML 구성 파일을 열어 직접 수정할 수 있습니다.

1. 기본 구조
   kubectl edit [리소스 종류] [리소스 이름]
   
   예시: kubectl edit deployment my-deployment
   (my-deployment 이름의 디플로이먼트 리소스의 YAML 구성 파일을 열고 직접 수정할 수 있습니다.)
   
   * 수정한 후에는 파일을 저장하고 종료하면, Kubernetes API 서버에 변경 내용이 자동으로 적용됩니다.
   
   
2. 옵션
   
   • --namespace: 리소스가 포함된 네임스페이스를 지정합니다.
     
     예시: kubectl edit deployment my-deployment --namespace my-namespace
      (my-namespace 네임스페이스에 속한 my-deployment 이름의 디플로이먼트 리소스의 YAML 구성 파일을 열고 직접 수정할 수 있습니다.)
     
     
   • --filename: 파일에서 YAML 구성을 읽어옵니다.
     
     예시: kubectl edit --filename=my-deployment.yaml
      (my-deployment.yaml 파일에서 디플로이먼트 리소스의 YAML 구성을 읽어와 수정할 수 있습니다.)
     
     
   • --output: 출력 형식을 지정합니다.
     
     예시: kubectl edit deployment my-deployment --output=yaml
      (my-deployment 이름의 디플로이먼트 리소스의 YAML 구성을 편집한 후, YAML 형식으로 출력합니다.)

kubectl label 

kubectl label 명령어는 Kubernetes 리소스에 레이블을 추가, 수정 또는 제거하는 명령어입니다. 이 명령어를 사용하면, 리소스를 논리적으로 그룹화하거나 검색할 때 유용한 정보를 리소스에 추가할 수 있습니다.

1. 기본 구조
   kubectl label [리소스 종류] [리소스 이름] [레이블 이름]=[레이블 값]
   
   예시: kubectl label pods my-pod app=my-app
   (my-pod 이름의 파드에 app=my-app 레이블을 추가할 수 있습니다.)
   
   
2. 옵션
   
   • --overwrite: 이미 존재하는 레이블 값을 덮어쓰기 합니다.
     
     예시: kubectl label pods my-pod app=my-new-app --overwrite
      (my-pod 이름의 파드에 이미 존재하는 app 레이블 값을 my-new-app으로 덮어씁니다.)
     
     
   • --namespace: 리소스가 포함된 네임스페이스를 지정합니다.
     
     예시: kubectl label pods my-pod app=my-app --namespace my-namespace
      (my-namespace 네임스페이스에 속한 my-pod 이름의 파드에 app=my-app 레이블을 추가합니다.)
     
     
   • --selector: 레이블을 추가할 리소스를 선택합니다.
     
     예시: kubectl label pods --selector app=my-app release=beta 
     (app=my-app 레이블을 가진 모든 파드에 release=beta 레이블을 추가합니다.)

kubectl annotate

kubectl annotate 명령어는 Kubernetes 리소스에 주석을 추가, 수정 또는 제거하는 명령어입니다. 이 명령어를 사용하면, 리소스에 부가적인 정보를 추가하거나 메타데이터를 관리할 수 있습니다.

1. 기본 구조
   kubectl annotate [리소스 종류] [리소스 이름] [주석 이름]=[주석 값]
   
   예시: kubectl annotate pods my-pod description="This is my pod"
   (my-pod 이름의 파드에 description="This is my pod" 주석을 추가할 수 있습니다.)
   
   
2. 옵션
   
   • --overwrite: 이미 존재하는 주석 값을 덮어쓰기 합니다.
     
     예시: kubectl annotate pods my-pod description="This is my new pod" --overwrite
      (my-pod 이름의 파드에 이미 존재하는 description 주석 값을 This is my new pod으로 덮어씁니다.)
     
     
   • --namespace: 리소스가 포함된 네임스페이스를 지정합니다.
     
     예시: kubectl annotate pods my-pod description="This is my pod" --namespace my-namespace 
     (my-namespace 네임스페이스에 속한 my-pod 이름의 파드에 description="This is my pod" 주석을 추가합니다.)

kubectl exec

kubectl exec 명령어는 Kubernetes 파드 내부에서 실행 중인 컨테이너에 명령어를 실행하는 명령어입니다. 이 명령어를 사용하면, 파드 내부에서 작업을 수행하거나 디버깅을 위해 컨테이너 내부로 들어갈 수 있습니다.

1. 기본 구조
   kubectl exec [옵션] [파드 이름] -- [컨테이너 이름] [명령어]
   
   예시: kubectl exec my-pod -- ls /app
   (my-pod 이름의 파드 내부에서 /app 디렉토리를 조회할 수 있습니다.)
   
   
2. 옵션
   
   • --namespace: 파드가 포함된 네임스페이스를 지정합니다.
     
     예시: kubectl exec my-pod --namespace my-namespace -- ls /app 
     (my-namespace 네임스페이스에 속한 my-pod 이름의 파드 내부에서 /app 디렉토리를 조회할 수 있습니다.)
     
     
   • --stdin, -i: 컨테이너의 표준 입력을 연결합니다.
     
     예시: kubectl exec my-pod -i -- ls /app
      (my-pod 이름의 파드 내부에서 /app 디렉토리를 조회하면서 컨테이너의 표준 입력을 연결합니다.)
     
     
   • --tty, -t: TTY 모드를 사용합니다.
     
     예시: kubectl exec my-pod -t -- bash 
     (my-pod 이름의 파드 내부에서 Bash 셸을 실행하면서 TTY 모드를 사용합니다.)

kubectl wait

kubectl wait 명령어는 특정 리소스가 특정 조건을 만족할 때까지 대기하는 명령어입니다. 이 명령어를 사용하면, 리소스의 상태를 주기적으로 체크하여 지정된 조건이 충족될 때까지 기다릴 수 있습니다.

1. 기본적인 사용 방법은 다음과 같습니다.
   kubectl wait [리소스 종류] [리소스 이름] --for=[조건] [조건 값]
   
   예시: kubectl wait pod my-pod --for=condition=Ready
   (my-pod 파드가 Ready 상태가 될 때까지 대기할 수 있습니다.)
   
   
2. 옵션
   
   • --for: 대기할 조건을 지정합니다.
     
     예시: kubectl wait pod my-pod --for=condition=Ready 
     (Ready 조건이 충족될 때까지 대기합니다.)
     
     
   • --timeout: 대기 시간을 지정합니다. 이 시간을 초과하면 명령어가 종료됩니다.
     
     예시: kubectl wait pod my-pod --for=condition=Ready --timeout=60s 
     (Ready 조건이 충족될 때까지 60초 동안 대기합니다.)
     
     
   • --namespace: 네임스페이스를 지정합니다.
     
     예시: kubectl wait pod my-pod --for=condition=Ready --namespace=my-namespace
      (my-namespace 네임스페이스에 있는 my-pod 파드가 Ready 상태가 될 때까지 대기합니다.)

항상 그렇듯 여기 있는 명령어 옵션이 전부가 아니며 --help를 통해 더 다양한 명령어를 찾아보실 수 있습니다.

목차

1. 파드 관련
   1. kubectl create
   2. kubectl run
   3. kubectl delete
   4. kubectl cp
2. 노드 관련
   1. kubectl cordon
   2. kubectl drain

Kubectl create

kubectl create 명령어는 Kubernetes에서 새로운 리소스를 생성할 때 사용하는 명령어입니다. 이 명령어를 사용하면 간단한 YAML 파일을 작성하지 않고도 명령어 자체에서 리소스를 생성할 수 있습니다.

1. 기본 구조
   
   • kubectl create [리소스 종류] [리소스 이름]
2. 자주 사용되는 리소스 종류
   
   • Pod: kubectl create pod
     
     예시: kubectl create pod my-pod --image=nginx 
     (Nginx 이미지를 사용하는 my-pod 이름을 가진 Pod 리소스를 생성합니다.)
     
     
   • Deployment: kubectl create deployment
     
     예시: kubectl create deployment my-deployment --image=nginx
      (Nginx 이미지를 사용하는 my-deployment 이름을 가진 Deployment 리소스를 생성합니다.)
     
     
   • Service: kubectl create service
     
     예시: kubectl create service clusterip my-service --tcp=80:8080 
     (80 포트를 8080 포트로 매핑하는 my-service 이름을 가진 ClusterIP Service 리소스를 생성합니다.)
     
     
   • ConfigMap: kubectl create configmap
     
     예시: kubectl create configmap my-config --from-literal=key1=value1 --from-literal=key2=value2
     (key1=value1, key2=value2 데이터를 가진 my-config 이름을 가진 ConfigMap 리소스를 생성합니다.)
     
     
   • Secret: kubectl create secret
     
     예시: kubectl create secret generic my-secret --from-literal=password=1234 
     (password=1234 데이터를 가진 my-secret 이름을 가진 Secret 리소스를 생성합니다.)
     
     
3. 옵션
   
   
   • --dry-run: 리소스를 생성하지 않고 생성 결과만 미리 확인합니다.
     
     예시: kubectl create deployment my-deployment --image=nginx --dry-run
     
     
   • -o, --output: 생성한 리소스의 정보를 출력 형식을 지정합니다. json 또는 yaml 형식을 사용할 수 있습니다.
     
     예시: kubectl create deployment my-deployment --image=nginx -o json
      (JSON 형식으로 생성한 디플로이먼트 리소스 정보를 출력합니다.)
     
     
   • --save-config: 리소스를 생성할 때, 생성한 리소스의 구성을 클러스터 상태 저장소에 저장합니다.
     
     예시: kubectl create deployment my-deployment --image=nginx --save-config 
     (Nginx 이미지를 사용하는 my-deployment 이름을 가진 Deployment 리소스를 생성하면서, 리소스의 구성을 클러스터 상태 저장소에 저장합니다.)
     
     
   • --image: Pod 또는 Deployment 리소스를 생성할 때, 사용할 컨테이너 이미지를 지정합니다.
     
     예시: kubectl create pod my-pod --image=nginx
     (Nginx 이미지를 사용하는 my-pod 이름을 가진 Pod 리소스를 생성합니다.)
     
     
   • -f, --filename: YAML 또는 JSON 파일을 사용하여 리소스를 생성합니다.
     
     예시: kubectl create -f pod.yaml 
     (pod.yaml 파일에 정의된 Pod 리소스를 생성합니다.)
     
     
   • -n, --namespace: 리소스가 생성될 네임스페이스를 지정합니다.
     
     예시: kubectl create deployment my-deployment --image=nginx -n my-namespace
      (my-deployment 이름을 가진 Deployment 리소스를 my-namespace 네임스페이스에 생성합니다.)
     
     
   • --restart-policy: 컨테이너의 재시작 정책을 지정합니다. Always, OnFailure, Never 중 하나를 선택할 수 있습니다.
     
     예시: kubectl create pod my-pod --image=nginx --restart-policy=OnFailure
     (Nginx 이미지를 사용하는 my-pod 이름을 가진 Pod 리소스를 생성하면서, 컨테이너의 재시작 정책을 OnFailure로 지정합니다.)

Kubectl run

kubectl run 명령어는 Kubernetes 클러스터에서 파드나 작업을 생성하는 명령어입니다. 이 명령어를 사용하면 이미지를 생성하고 바로 실행을 합니다. 단 create는 여러 개를 한번에 생성 가능하지만 run은 불가능합니다.

1. 기본 구조
   
   • kubectl run [파드 이름] --image=[이미지 이름]
     
     예시: kubectl run nginx --image=nginx 명령어를 실행하여 nginx 이미지를 실행하는 nginx 파드를 생성할 수 있습니다.
2. 옵션
   
   • --image: 실행할 이미지 이름을 지정합니다.
     
     예시: kubectl run nginx --image=nginx 
     (nginx 이미지를 사용하여 파드를 생성합니다.)
     
     
   • --replicas: 생성할 파드나 작업의 개수를 지정합니다.
     
     예시: kubectl run nginx --image=nginx --replicas=3 
     (nginx 이미지를 사용하여 파드를 3개 생성합니다.)
     
     
   • --port: 파드나 작업에서 노출할 포트 번호를 지정합니다.
     
     예시: kubectl run nginx --image=nginx --port=80
      (nginx 이미지를 사용하여 파드를 생성하고, 80번 포트를 노출합니다.)

Kubectl delete

kubectl delete 명령어는 Kubernetes 클러스터에서 리소스를 삭제하는 데 사용됩니다. 이 명령어는 다양한 종류의 Kubernetes 리소스를 삭제하는 데 사용됩니다. 예를 들어, 파드, 서비스, 볼륨, 네임스페이스 등을 삭제할 수 있습니다.

1. 기본 구조
   
   • kubectl delete <리소스 유형> <리소스 이름>
     
     예시: 파드를 삭제하려면 다음과 같이 입력합니다.
     kubectl delete pod <파드 이름>
2. 옵션
   
   • --all: 모든 리소스를 삭제합니다.
   • --force: 강제 삭제합니다.
   • --grace-period=<초>: 삭제될 때 대기할 시간을 초 단위로 설정합니다.
   • --timeout=<초>: 명령이 실행될 때 대기할 최대 시간을 초 단위로 설정합니다.
     
     예시: kubectl delete pod --all --force
     (모든 파드를 강제로 삭제합니다.)
     
     예시2: kubectl delete all --all
     (모든 종류의 리소스와 파드를 삭제합니다.)

kubectl cp

kubectl cp 명령어는 Kubernetes 클러스터 내부의 파일을 호스트 머신으로 복사하거나 호스트 머신의 파일을 클러스터 내부로 복사하는 명령어입니다. 이 명령어를 사용하면, 파드 내부에 있는 파일을 로컬 머신으로 복사하거나 로컬 머신의 파일을 파드 내부로 복사할 수 있습니다.

1. 기본적인 사용 방법은 다음과 같습니다.
   
   • kubectl cp [소스] [대상]
     
     예시: kubectl cp /path/to/local/file my-pod:/path/to/destination
     (로컬 머신의 /path/to/local/file 파일을 my-pod 파드의 /path/to/destination 경로로 복사할 수 있습니다.)
2. 옵션
   
   • -c, --container: 컨테이너 이름을 지정합니다.
     
     예시: kubectl cp /path/to/local/file my-pod:/path/to/destination -c my-container
      (my-pod 파드의 my-container 컨테이너 내부의 /path/to/destination 경로에 로컬 머신의 /path/to/local/file 파일을 복사합니다.)
     
     
   • --no-preserve: 파일 속성을 유지하지 않습니다.
     
     예시: kubectl cp /path/to/local/file my-pod:/path/to/destination --no-preserve 
     (my-pod 파드의 /path/to/destination 경로에 로컬 머신의 /path/to/local/file 파일을 복사하되, 속성은 유지하지 않습니다.)

위에서 다룬 명령어들과의 차이점은 이제까지는 파드나 리소스를 건들였지만, 이번에는 노드 자체를 건드리는 것입니다.

kubectl cordon

kubectl cordon 명령어는 Kubernetes 노드를 Scheduling 하지 않도록 설정하는 명령어입니다. 노드를 cordon 처리하면 해당 노드에 있는 파드들은 다른 노드로 이동하지 않고 그대로 유지됩니다.

1. 기본 구조
   • kubectl cordon [노드 이름]
     
     예시: kubectl cordon my-node
     (my-node 이름을 가진 노드를 Scheduling 하지 않도록 설정합니다.)
2. 옵션
   
   • --ignore-daemonsets: 데몬셋을 무시하고 노드를 cordon 처리합니다.
     
     예시: kubectl cordon my-node --ignore-daemonsets
      (my-node 이름을 가진 노드를 Scheduling 하지 않도록 설정하면서, 데몬셋을 무시합니다.)
     
     
   • --dry-run: 노드를 cordon 처리하지 않고 처리 결과만 미리 확인합니다.
     
     예시: kubectl cordon my-node --dry-run 
     (my-node 이름을 가진 노드를 Scheduling 하지 않도록 설정하지 않고, 처리 결과만 미리 확인합니다.)
     
     
   • --selector: cordon 처리할 노드를 선택합니다. label selector를 지정하여 여러 노드를 선택할 수 있습니다.
     
     예시: kubectl cordon --selector="region=us-west"
      (region이 us-west인 노드를 모두 cordon 처리합니다.)
     
     
   • --timeout: cordon 처리할 때, 타임아웃을 설정합니다.
     
     예시: kubectl cordon my-node --timeout=60s
     (my-node 이름을 가진 노드를 Scheduling 하지 않도록 설정하면서, 타임아웃을 60초로 설정합니다.)

kubectl drain

kubectl drain 명령어는 Kubernetes 노드에서 파드를 안전하게 제거한 후, 노드를 비활성화할 때 사용하는 명령어입니다. drain 명령어를 사용하면 노드를 삭제하기 전에 파드를 안전하게 다른 노드로 이동할 수 있습니다.

1. 기본 구조
   
   1. kubectl drain [노드 이름]
      
      예시: kubectl drain my-node
      (my-node 이름을 가진 노드에서 실행 중인 파드를 안전하게 다른 노드로 이동하고, 노드를 비활성화합니다.)
2. 옵션
   
   • --ignore-daemonsets: 데몬셋을 무시하고 파드를 다른 노드로 이동합니다.
     
     예시: kubectl drain my-node --ignore-daemonsets 
     (my-node 이름을 가진 노드에서 실행 중인 파드를 안전하게 다른 노드로 이동하면서, 데몬셋을 무시합니다.)
     
     
   • --delete-local-data: 파드에서 사용하는 로컬 디스크 데이터를 삭제합니다.
     
     예시: kubectl drain my-node --delete-local-data 
     (my-node 이름을 가진 노드에서 실행 중인 파드를 안전하게 다른 노드로 이동하면서, 파드에서 사용하는 로컬 디스크 데이터를 삭제합니다.)
     
     
   • --force: 파드가 정상적으로 종료되지 않더라도 파드를 강제로 이동합니다.
     
     예시: kubectl drain my-node --force
      (my-node 이름을 가진 노드에서 실행 중인 파드를 안전하게 다른 노드로 이동하면서, 파드가 정상적으로 종료되지 않더라도 강제로 이동합니다.)
     
     
   • --grace-period: 파드가 삭제되기 전 대기하는 시간(초)을 설정합니다.
     예시: kubectl drain my-node --grace-period=30
      (my-node 이름을 가진 노드에서 실행 중인 파드를 안전하게 다른 노드로 이동하면서, 파드가 삭제되기 전 30초간 대기합니다.)
     
     
   • -n, --namespace: 파드가 위치한 네임스페이스를 지정합니다.
     예시: kubectl drain my-node -n my-namespace
      (my-node 이름을 가진 노드에서 실행 중인 파드를 안전하게 다른 노드로 이동하면서, my-namespace 네임스페이스에 위치한 파드를 이동합니다.)

이 외에도 여러 종류의 옵션이 있을 수 있습니다. 해당 내용은 명렁어 + --help를 입력하시면 더 다양한 옵션들을 찾을 수 있을 것입니다. 해당 시리즈(kubectl, kubeadm 명령어 모음)은 총 7개 포스팅으로 이뤄질 예정입니다.

목차

1. 애플리케이션 서비스 구성 요소
2. 애플리케이션 배포, 운영
3. 파드와 컨테이너
4. 서비스가 필요한 이유

애플리케이션 서비스 구성 요소

클러스터에 대해 알기 위해 우리는 그 구성요소에 무엇이 있고, 어떤 동작을 하는지 알 필요가 있습니다. 이 중 파드에 대해서는 자세히 설명한 바 있고, 레플리케이션 컨트롤러가 무엇인지, 쿠버네티스에서 말하는 서비스는 무엇인지 알아보도록 하겠습니다.

1. 레플리케이션 컨트롤러
   레플리케이션 컨트롤러는 쿠버네티스에서 파드를 관리하는 컨트롤러 중 하나입니다. 레플리케이션 컨트롤러는 사용자가 지정한 파드의 복제본(replica) 개수를 유지하도록 하며, 파드의 스케일링과 롤링 업데이트 등을 수행합니다.
   
   레플리케이션 컨트롤러는 파드의 상태를 모니터링하고, 복제본 개수를 조정하여 원하는 상태를 유지합니다. 파드가 삭제되면 레플리케이션 컨트롤러는 새로운 파드를 생성하여 복제본 개수를 유지합니다. 따라서 파드의 안정적인 운영을 보장할 수 있습니다.
   
   레플리케이션 컨트롤러는 디플로이먼트 컨트롤러와 함께 사용되어, 애플리케이션의 롤링 업데이트를 수행할 수 있습니다. 디플로이먼트 컨트롤러는 레플리케이션 컨트롤러를 이용하여 파드를 업데이트하며, 업데이트 과정에서 롤백 기능도 제공합니다.
2. 서비스
   쿠버네티스에서 서비스는 일련의 파드 집합에 대한 네트워크 엔드포인트를 제공하는 리소스입니다. 서비스는 파드의 IP 주소와 포트 번호를 추상화하여, 클러스터 내부 또는 외부에서 파드에 접근할 수 있는 방법을 제공합니다.
   
   서비스는 쿠버네티스 클러스터 내에서 파드 간의 통신을 위한 로드 밸런싱, 서비스 디스커버리, 서비스 간의 연결 등 다양한 기능을 제공합니다. 클러스터 내부에서는 DNS를 이용하여 서비스 이름으로 파드에 접근할 수 있으며, 클러스터 외부에서는 로드 밸런서나 노드포트를 이용하여 서비스에 접근할 수 있습니다.
   
   서비스는 또한 셀렉터(selector)를 이용하여 특정 라벨을 가진 파드를 선택하고, 해당 파드들에 대한 엔드포인트를 생성합니다. 이를 통해 파드의 스케일링이나 롤링 업데이트 등의 작업이 수행되어도 서비스의 엔드포인트는 변경되지 않으므로, 안정적인 서비스 제공이 가능합니다.
   
   
3. 파드
   Pod에 관해서는 아래 페이지에 상세히 정리해 놓았습니다.

애플리케이션 배포, 운영

우선, 들어가기에 앞서 각 구성 요소의 역할을 간단히 다시 정리하자면 다음과 같습니다.

1. 레플리케이션 컨트롤러는 사용자가 지정한 파드의 복제본(replica) 개수를 유지하도록 합니다. 이를 통해 파드의 안정적인 운영을 보장할 수 있습니다.
   
   
2. 파드는 쿠버네티스에서 배포되는 가장 작은 단위의 컨테이너입니다. 각 파드는 고유한 IP 주소와 포트 번호를 가지며, 컨테이너화된 애플리케이션을 실행합니다.
   
   
3. 서비스는 파드의 집합에 대한 네트워크 엔드포인트를 제공합니다. 서비스는 파드의 IP 주소와 포트 번호를 추상화하여, 클러스터 내부 또는 외부에서 파드에 접근할 수 있는 방법을 제공합니다. 서비스는 쿠버네티스 클러스터 내에서 파드 간의 통신을 위한 로드 밸런싱, 서비스 디스커버리, 서비스 간의 연결 등 다양한 기능을 제공합니다.
   
   

이러한 레플리케이션 컨트롤러, 파드, 서비스는 함께 동작하여 쿠버네티스에서 애플리케이션을 배포하고 운영합니다. 우선, 레플리케이션 컨트롤러는 사용자가 지정한 파드의 복제본 개수를 유지하도록 합니다. 이 때, 레플리케이션 컨트롤러는 파드의 라벨을 이용하여 복제본을 관리합니다. 레플리케이션 컨트롤러는 파드의 상태를 모니터링하고, 복제본 개수를 조정하여 원하는 상태를 유지합니다.

서비스는 파드의 집합에 대한 네트워크 엔드포인트를 제공합니다. 이를 통해 클러스터 내부 또는 외부에서 파드에 접근할 수 있습니다. 서비스는 파드의 라벨 셀렉터를 이용하여 파드를 선택하고, 해당 파드들에 대한 엔드포인트를 생성합니다. 이를 통해 파드의 스케일링이나 롤링 업데이트 등의 작업이 수행되어도 서비스의 엔드포인트는변경되지 않으므로, 안정적인 서비스 제공이 가능합니다.

따라서, 레플리케이션 컨트롤러는 파드의 안정적인 운영을 보장하며, 서비스는 파드의 집합에 대한 안정적인 네트워크 엔드포인트를 제공합니다. 이를 통해 쿠버네티스에서 애플리케이션을 안정적으로 배포하고 운영할 수 있습니다.

예를 들어, 사용자가 레플리케이션 컨트롤러를 이용하여 파드의 복제본을 3개로 지정하면, 레플리케이션 컨트롤러는 3개의 파드를 생성합니다. 이때, 레플리케이션 컨트롤러는 파드의 라벨을 이용하여 복제본을 관리합니다. 서비스는 이 세 개의 파드에 대한 네트워크 엔드포인트를 생성하고, 클러스터 내부 또는 외부에서 이 서비스에 접근할 수 있습니다.

파드가 스케일링되거나 롤링 업데이트가 수행될 경우, 레플리케이션 컨트롤러는 이를 감지하고 파드의 복제본 개수를 조정합니다. 서비스는 파드의 라벨 셀렉터를 이용하여 파드를 선택하고, 변경된 파드에 대한 엔드포인트를 생성합니다. 이를 통해 파드의 스케일링이나 롤링 업데이트 등의 작업이 수행되어도 서비스의 엔드포인트는 변경되지 않으므로, 안정적인 서비스 제공이 가능합니다.

파드와 컨테이너

컨테이너는 사용자 스스로 직접 생성하거나 동작시키지 않습니다. 대신 쿠버네티스의 기본 빌딩 블록인 파드를 이용합니다. 그러나 파드도 직접 생하는 것은 아닙니다. kubectl run 명령어를 이용해 레플리케이션 컨트롤러를 생성하고 레플리케이션 컨트롤러가 실제 파드를 생성하는 방식입니다. 클러스터 외부에서 파드에 접근하기 위해 쿠버네티스에게 레플리케이션 컨트롤러에 의해 관리되는 모든 파드를 단일 서비스로 노출하도록 명령합니다.

시스템의 가장 중요한 구성 요소는 파드입니다. 파드는 자체 고유한 사설 IP 주소와 이름을 갖습니다. 그라고 보통 파드는 원하는 만큼 컨테이너를 포함시킬 수 있습니다. 하지만 컨테이너를 마구잡이로 생성하는 것 보다 하나의 파드에는 하나의 컨테이너 사용을 권장하고 있습니다. 이 내용에 대해서는 위에 파드에 대해 정리해 놓은 페이지에 자세히 정리해 놓았습니다.

서비스가 필요한 이유

시스템의 세 번째 구성 요소는 kubia-http 서비스입니다. 서비스가 필요한 이유를 이해하기 위해 파드의 주요 특징에 대해 알아야 합니다. 파드는 일시적이라고 말씀드린 바 있습니다. 즉, 파드는 언제든 사라질 수 있습니다. 파드가 실행 중인 노드가 실패할 수도 있고 누군가 파드를 삭제할 수도 있고, 비정상 노드에서 파드가 제거될 수 있습니다.

이러한 상황이 발생하면 앞서 설명한 대로 사라진 파드는 레플리케이션 컨트롤러에 의해 생성된 파드로 대체됩니다. 새로운 파드는 다른 IP 주소를 할당받습니다. 이것이 바로 서비스가 필요한 이유입니다. 항상 변경되는 파드의 IP 주소 문제와 여러 개의 파드를 단일 IP와 포트의 쌍으로 노출시키는 문제를 해결합니다.

서비스가 생성되면 정적 IP를 할당받고 서비스가 존속하는 동안 변경되지 않습니다. 파드에 직접 연결하는 대신 클라이언트는 서비스 IP 주소를 통해 연결해야 합니다. 서비스는 어떤 파드가 어디에서 존재하는지에 관계없이 파드 중 하나로 연결해 요청을 처리하도록 합니다.

서비스는 동일한 서비스를 제공하는 하나 이상의 파드 그룹의 정적 위치를 나타냅니다. 서비스의 IP와 포트로 유입된 요처은 그 순간 서비스에 속해 있는 파드 중 하나에게 전달됩니다.

목차

1. 도커 이미지 빌드 방식
2. 도커 이미지 빌드 과정 예시
3. 이미지 빌드 특징
4. 도커 이미지 레이어
5. Dockerfile을 이용한 이미지 빌드 vs 수동 빌드

이전 도커 명령어를 다루는 과정에서 이미지 빌드에 대해 설명한 바 있습니다. 이에 대한 내용을 좀 더 자세히 다뤄보려고 합니다. 실습도 중요하지만, 단순히 타이핑만 하는 것 보다 원리를 알고 사용하면 더 좋으니까 말이죠. 도커 명령어에 대해 자세히 알고 싶으시다면 다음 페이지를 이용하시면 되겠습니다.

도커 이미지 빌드 방식

Dockerfile은 Docker 이미지를 빌드하기 위한 일련의 지침이 포함된 스크립트입니다. Dockerfile을 만드는 방법에는 여러 가지가 있습니다.

1. Dockerfile 수동 생성
   Vim, Nano 또는 Notepad와 같은 텍스트 편집기를 사용하여 Dockerfile을 수동으로 생성할 수 있습니다. 새 파일을 열고 Dockerfile과 같은 이름을 지정하고 올바른 형식으로 지침을 추가하기만 하면 됩니다.
   
   
2. Dockerfile 생성기 사용
   Dockerfile 생성기와 같은 일부 도구는 운영 체제 유형, 프로그래밍 언어, 버전 및 기타 종속성과 같은 특정 구성 세부 정보를 기반으로 Dockerfile을 자동으로 생성할 수 있습니다.
   
   
3. 기본 이미지 사용
   Docker Hub에서 사용할 수 있는 기존 기본 이미지를 사용하여 Dockerfile을 생성할 수도 있습니다. 기본 이미지는 애플리케이션을 실행하기 위한 최소한의 요구 사항을 포함하는 최소한의 이미지입니다.
   
   
4. 타사 도구 사용
   Docker 이미지를 생성할 수 있는 Packer, Ansible 및 Chef와 같은 여러 타사 도구가 있습니다. 이러한 도구는 Dockerfile 생성을 자동화하고 이미지 구성을 관리할 수도 있습니다.
   
   
5. Dockerfile 템플릿 사용
   Dockerfile 템플릿은 Dockerfile 생성에 대한 구조화된 접근 방식을 제공합니다. Cookiecutter와 같은 도구를 사용하여 표준 지침을 포함하고 사용자 지정을 허용하는 템플릿을 만들 수 있습니다.

Dockerfile을 만드는 데 사용되는 방법에 관계없이 빌드 프로세스 중에 문제를 방지하려면 파일이 올바른 구문과 구조를 따르는지 확인하는 것이 중요합니다.

도커 이미지 빌드 과정 예시

1. Dockerfile 만들기
   첫 번째 단계는 Docker 이미지를 빌드하기 위한 일련의 지침이 포함된 텍스트 파일인 Dockerfile을 만드는 것입니다. Dockerfile은 무엇보다도 기본 이미지를 지정하고 환경 변수를 설정하며 파일을 이미지에 복사합니다.
   
   
2. 터미널 열기
   로컬 컴퓨터에서 터미널을 열고 Dockerfile이 있는 디렉터리로 이동합니다.
   
   
3. docker build 명령 실행
   Dockerfile에서 이미지를 빌드하려면 적절한 옵션과 함께 docker build 명령을 실행합니다. 예를 들어 docker build -t myimage:1.0 .은 현재 디렉터리의 Dockerfile을 사용하여 myimage:1.0 태그가 지정된 이미지를 빌드합니다.
   
   
4. Docker는 Dockerfile을 읽습니다
   docker build 명령을 실행하면 Docker는 Dockerfile을 한 줄씩 읽고 각 명령을 실행합니다.
   
   
5. 기본 이미지 다운로드
   Dockerfile에 지정된 기본 이미지를 다운로드하여 Docker가 시작됩니다. 이것이 이미지 구축의 출발점입니다.
   
   
6. Dockerfile의 각 명령 실행
   그런 다음 Docker는 패키지 설치 또는 파일 복사와 같은 Dockerfile의 각 명령을 실행합니다.
   
   
7. 새 이미지 만들기
   Dockerfile의 모든 지침이 실행되면 Docker가 새 이미지를 만듭니다.
   
   
8. 새 이미지 저장
   새 이미지는 Docker의 로컬 이미지 레지스트리에 저장됩니다. docker images 명령을 사용하여 로컬 컴퓨터의 모든 이미지 목록을 볼 수 있습니다.
   
   
9. 새 이미지 사용
   이미지가 빌드되면 docker run 명령을 사용하여 컨테이너를 실행하는 데 사용할 수 있습니다. 예를 들어 docker run -d -p 80:80 myimage:1.0은 포트 80에서 myimage:1.0 이미지를 사용하여 컨테이너를 시작합니다.
   
   
10. 이미지를 레지스트리로 푸시(선택 사항)
    이미지를 다른 사람과 공유하려는 경우 Docker 허브 또는 프라이빗 레지스트리와 같은 레지스트리로 이미지를 푸시할 수 있습니다. 이렇게 하면 다른 사람이 이미지를 다운로드하고 사용할 수 있습니다.

전반적으로 docker build 명령은 사용자 정의 Docker 이미지를 생성하기 위한 강력한 도구입니다. 위에서 설명한 단계를 따르면 초보자도 Docker 이미지를 만들고 사용하여 애플리케이션을 배포할 수 있습니다.

이미지 빌드 특징

빌드 프로세스는 도커 클라이언트가 수행하지 않습니다. 그 대신 디렉터리의 전체 콘텐츠가 도커 데몬에 업로드되고 그곳에서 이미지가 빌드됩니다. 또한, 도커 클라이언트와 데몬은 같은 머신에 있을 필요는 없습니다.

리눅스가 아닌 OS에서 도커를 사용하는 경우 도커 클라이언트는 호스트 OS에 위치하고, 데몬은 가상머신 내부에서 실행됩니다. 빌드 디렉터리의 모든 파일이 데몬에 업로드돼야 하기 때문에 데몬이 로컬로 실행 중이지 않은 상황에서 큰 파일이 다수 포함되면 업로드 시간이 오래 걸릴 수 있습니다. 빌드 프로세스 동안 이미지가 사용자 컴퓨터에 저장돼 있지 않다면, 도커는 기본 이미지를 퍼블릭 이미지 리포지터리(도커 허브)에서 가져옵니다.

도커 이미지 레이어

Docker 이미지는 기본적으로 특정 시점의 파일 시스템 스냅샷인 여러 레이어로 구성됩니다. 각 레이어는 해당 이미지를 구성하는데 필요한 파일이나 디렉토리, 설정, 라이브러리 등의 정보를 담고 있고, 새 파일 추가 또는 기존 파일 수정과 같이 파일 시스템에 대한 특정 변경 사항을 나타냅니다.

docker build 명령을 사용하여 Docker 이미지를 빌드할 때 Dockerfile의 각 행은 새 레이어를 나타냅니다. 예를 들어 Dockerfile에 패키지를 설치하기 위한 RUN 명령이 포함된 경우 Docker는 해당 패키지가 설치된 새 레이어를 생성합니다. Dockerfile에 RUN 명령이 여러 개 있으면 각각 새 레이어를 만듭니다. 이 때 이전 레이어의 내용은 그대로 유지되고 새로운 레이어에 추가됩니다.

Docker 이미지 레이어의 중요한 기능 중 하나는 변경할 수 없다는 것입니다. 즉, 일단 생성되면 변경할 수 없습니다. 이는 Docker 이미지 작업에 여러 가지 의미가 있습니다.

• 이미지 간에 레이어 공유 가능
  동일한 기본 이미지에서 여러 이미지를 빌드하는 경우 동일한 레이어를 재사용할 수 있으므로 시간과 디스크 공간을 절약할 수 있습니다.
  
  
• 레이어를 캐시할 수 있음
  레이어는 변경할 수 없기 때문에 Docker는 레이어를 로컬로 캐시하고 변경되지 않은 경우 재사용할 수 있습니다. 이렇게 하면 동일한 레이어를 사용하는 후속 이미지의 빌드 프로세스 속도를 높일 수 있습니다.
  
  
• 레이어 검사 가능
  docker history 명령을 사용하여 Docker 이미지를 구성하는 레이어를 검사할 수 있습니다. 이는 이미지 빌드 방법을 이해하고 문제를 해결하는 데 유용할 수 있습니다.

Docker 이미지는 레이어화된 파일 시스템을 사용하므로 이미지를 효율적으로 저장하고 배포할 수 있습니다. 이미지를 업데이트할 때는 변경된 부분만 새로운 레이어로 추가하므로 이전 레이어는 그대로 유지됩니다. 이를 통해 이미지의 용량이 크게 감소하고 더욱 빠른 배포가 가능해집니다. 각 레이어는 별도의 파일로 저장되며 레이어는 런타임에 결합되어 컨테이너의 최종 파일 시스템을 생성합니다.

하지만 이러한 레이어 구조는 이미지가 커질수록 관리가 어려워지기도 합니다. 각 레이어마다 수정이 필요한 경우 해당 레이어를 수정하거나 새로운 레이어를 추가해야 하기 때문입니다. 따라서 이미지를 설계할 때는 레이어 구조와 관련된 특성을 고려하여 효율적인 구성을 고민해야 합니다.

Dockerfile을 이용한 이미지 빌드 vs 수동 빌드

Dockerfile을 사용하여 이미지를 빌드할 때 Dockerfile에 이미지를 생성하라는 명령을 사용자가 지정하면 Docker가 이를 읽고 실행하여 이미지를 생성하는 선언적 방식입니다. 동일한 Dockerfile을 사용하여 동일한 이미지를 여러 번 생성할 수 있으므로 이 방법은 반복 가능합니다. 또한 Git과 같은 소스 제어 시스템에서 Dockerfile의 변경 사항을 추적할 수 있으므로 이미지 생성 프로세스의 버전 제어가 가능합니다. Dockerfile을 사용하면 조건문 또는 인수를 사용하여 이미지의 차이점을 지정하여 단일 소스에서 여러 이미지를 만들 수 있습니다. 그러나 이 방법을 사용하려면 사용자가 Dockerfile 구문 및 모범 사례에 대한 지식이 있어야 합니다.

반면 수동 빌드는 실행 중인 컨테이너에서 명령을 수동으로 실행한 다음 변경 사항을 커밋하여 이미지를 생성하여 이미지를 생성하는 것입니다. 이 방법을 사용하면 사용자가 특정 종속성 또는 구성을 수동으로 설치할 수 있으므로 이미지 생성을 보다 세밀하게 제어할 수 있습니다. 그러나 이 방법은 이미지 생성 단계가 기록되지 않고 버전 제어가 쉽게 구현되지 않기 때문에 쉽게 반복할 수 없습니다. 또한 더 많은 수동 작업이 필요하며 사용자가 필요한 명령에 익숙하지 않은 경우 오류가 발생하기 쉽습니다.

정리하면, Dockerfile을 사용하여 이미지를 빌드하면 이미지 생성을 위한 반복 가능하고 버전 제어가 가능한 선언적 방법을 제공하는 반면, 수동 빌드는 보다 세밀한 제어가 가능하지만 쉽게 반복할 수 없고 버전 제어가 부족합니다. 초보자의 경우 더 간단하고 표준화된 접근 방식인 Dockerfile을 사용하여 이미지 빌드부터 시작하는 것이 좋습니다.