목차

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와 포트로 유입된 요처은 그 순간 서비스에 속해 있는 파드 중 하나에게 전달됩니다.

설치 전 유의 사항

이번 실습에서는 docker에서 이미지를 끌어와 하는 실습입니다. 다른 이미지 허브에서 다운로드 받으신다면 내용이 다소 다를 수 있으며, 제가 하는 쿠버네티스 실습은 베이스가 도커로 되어 있음을 알립니다. 물론 도커말고 다른 이미지 허브를 사용하셔도 전혀 문제는 없을 것으로 사료됩니다. 저처럼 도커를 이용하시려 한다면 도커를 VM에 다운로드 하는 방법은 아래 페이지에 들어가 보시면 됩니다.

kubenetes 다운로드

쿠버네티스는 설치가 다소 복잡합니다. 그래도 잘 따라올 수 있도록 작성해보겠습니다. 또한 이전 설명처럼 마스터와 워커 노드로 나뉘는데 이 중 마스터 노드는 코어는 최소 2개 이상, RAM도 2GB 이상 되어야 작동이 됩니다. 아래 내용 중 주석처리된(#) 내용을 입력해주시면 됩니다.

1. 쿠버네티스는 아직 스왑을 작동시킬 수 없습니다. 때문에 스왑을 off 해줘야 합니다.
   
   # swapon && cat /etc/fstab
   # swapoff -a && sed -i '/swap/s/^/#/' /etc/fstap
   
   
2. SELinux와 방화벽을 해제합니다. 저는 학습을 위한 환경으로 실제 업무에 이용하신다면 적절히 조율할 필요가 있습니다. 또한 이전 리눅스 명령어가 RedHat 기반이었던 것과는 반대로 컨테이너 과정은 ubuntu로 진행되어 ubuntu 기준으로 작성되었으니 이 점 유의해주시기 바랍니다.
   
   # setenfoce 0
   # ufw disable
   # systemctl stop firewalld
   # systemctl disable firewalld
   
   * 레드헷 기준 OS 는 다음 명령어를 입력하면 됩니다. 하지만 이는 학습환경을 위한 것이지 실무에서는 바로 전에 말한 것과 같이 이러한 환경은 적절하지 않을 수 있습니다.
   
   # grubby --update-kernel ALL --args selinux=0
   
   
3. Linux  노드의 iptables가 bridged traffic을 정확하게 확인하고 제어 할 수 있도록 br_netfilter 모듈을 load하고 관련된 네트워크 파라미터를 설정합니다.
   
   # lsmod | grep br_netfilter
   
   해당 명령어를 입력할 시 다음과 같은 내용이 출력돼야 합니다.
   
   br_netfilter           24576  0
   bridge                155648  1 br_netfilter
   
   이 내용이 나오지 않는다면 다음 명령어를 사용해 줍니다.
   
   # modprobe br_netfilter
   
   이후 이전 명령어인 lsmod ~ 를 입력해주어 앞서 말한 내용이 출력되는지 확인합니다.
   
   
4. 모듈과 네트워크 파라미터가 영구적으로 적재되도록 파일을 편집합니다.
   
   # cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
   br_netfilter
   EOF
   
   # cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
   net.bridge.bridge-nf-call-ip6tables = 1
   net.bridge.bridge-nf-call-iptables = 1
   EOF   
   sudo sysctl --system
   
   
5. 쿠버네티스와 부가 파일들을 설치해 줍니다.
   
   # sudo apt-get update
   # sudo apt-get install -y apt-transport-https ca-certificates curl
   
   # sudo curl -fsSLo /usr/share/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg
   
   # sudo apt-get update
   # sudo apt-get install -y kubelet kubeadm kubectl
   # sudo apt-mark hold kubelet kubeadm kubectl
   
   
6. cgroupfs를 컨테이너 런타임과 kubelet에 의해서 제어할 수 있도록 구성합니다.
   
   # sudo mkdir /etc/docker
   
   # cat <<EOF | sudo tee /etc/docker/daemon.json
   {
     "exec-opts": ["native.cgroupdriver=systemd"],
     "log-driver": "json-file",
     "log-opts": {
       "max-size": "100m"
     },
     "storage-driver": "overlay2"
   }
   EOF
   
   

여기까지 설치가 완료 되었습니다. 위 내용들은 말했던 것처럼 주석처리된 부분을 끝까지 입력해주면 설치가 완료되고 사용도 가능합니다. 이후에는 VM을 복사해 워커 노드를 생성해주고 IP를 다시 설정해 줍니다. 그리고 그 중 하나를 마스터 노드로 설정하면 컨테이너 환경의 구축이 마무리됩니다. 

다음 포스팅은 마스터 노드 지정 및 쿠버네티스 환경 구축에 대해 다뤄보려 합니다. 컨테이너에 들어서 다뤄야할 내용이 너무 많다보니 조금 늦어질 수 있을 듯하오니 양해 부탁드리겠습니다. 읽어주시는 독자분들에거 감사드리며 오늘 포스팅 마치도록 하겠습니다.

목차

1. 쿠버네티스의 구조
2. 각 구성 요소의 특징
3. 구성 요소 끼리의 통신
4. 각 구성 요소의 인스턴스 실행 방식 차이
5. 구성 요소 실행 방법

쿠버네티스의 구조

이전에 설명드렸던 쿠버네티스는 다음과 같은 구조로 되어 있습니다. 구성 요소들은  모두 개별 프로세스로 실행되고, 다음 그림에는 구성요소와 구성 요소 간의 종속성 또한 표현이 되어 있습니다.

쿠버네티스가 제공하는 기능을 온전히 사용하기 위해 이러한 구성요소들은 모두 실행 중이어야 합니다. 그러나 일부는 다른 구성 요소 없이도 개별적으로 유용한 작업을 실행할 수 있는데, 각 구성요소가 어떻게 작동하는지 살펴보려합니다.

각 구성 요소의 특징

1. etcd
   Kubernetes 컨트롤 플레인의 기본 데이터 저장소 역할을 하는 분산 키-값 저장소입니다. 이는 클러스터의 구성 데이터와 상태를 보유하여 클러스터의 상태가 일관되고 가용성이 높도록 보장하므로 Kubernetes의 중요한 구성 요소입니다. Etcd는 분산 시스템에서 고가용성과 내결함성을 유지할 수 있는 Raft 합의 알고리즘을 기반으로 합니다.
   
   Kubernetes 클러스터(위 사진)에서 etcd는 배포된 애플리케이션의 현재 상태, 원하는 상태, 클러스터 관리에 필요한 메타데이터와 같은 정보를 저장합니다. API 서버, 스케줄러 및 컨트롤러 관리자와 같은 Kubernetes 컨트롤 플레인 구성 요소는 etcd와 상호 작용하여 이 정보를 읽고 업데이트합니다.
   
   
2. API 서버
   Kubernetes 클러스터 내의 사용자, 관리자 및 기타 구성 요소 간의 기본 상호 작용 지점입니다. API 서버는 RESTful API 요청을 처리하고 유효성을 검사하며 etcd 데이터 저장소의 해당 개체를 업데이트합니다.
   
   API 서버는 클러스터의 상태를 관리하고 Kubernetes 컨트롤 플레인의 일관성, 보안 및 안정성을 보장하는 데 중요한 역할을 합니다. 사용자 및 구성 요소가 Kubernetes 클러스터와 상호 작용하여 인증, 권한 부여, 유효성 검사 및 승인 제어를 처리하는 기본 인터페이스 역할을 합니다.
   
   
3. 스케줄러
   스케줄러는 새로 생성되거나 예약되지 않은 파드를 클러스터 내의 적절한 노드에 할당하는 쿠버네티스 컨트롤 플레인의 핵심 구성 요소입니다. 주요 기능은 리소스 가용성, 제약 조건 및 정의된 정책을 기반으로 포드를 실행할 위치를 지능적으로 결정하여 워크로드가 클러스터 전체에 효율적으로 분산되도록 하는 것입니다.
   
   Kubernetes 클러스터 내에서 워크로드 및 리소스 활용의 효율적인 분산을 보장하는 데 중요한 역할을 합니다. 사용 가능한 리소스를 평가하고 제약 조건과 정책을 준수하며 확장 가능한 일정 알고리즘을 사용하여 포드 배치에 대한 지능적인 결정을 내립니다.
   
   
4. 컨트롤러 매니저
   컨트롤러 관리자는 클러스터의 원하는 상태를 자동화하고 유지 관리하는 다양한 컨트롤러를 관리하는 Kubernetes 제어 평면의 핵심 구성 요소입니다. 컨트롤러는 클러스터의 현재 상태를 지속적으로 모니터링하고 구성 파일 또는 API 개체에 지정된 원하는 상태와 일치하도록 필요한 조정을 수행하는 제어 루프입니다.
   
   Kubernetes 클러스터의 원하는 상태를 자동화하고 유지 관리하는 데 중요한 역할을 합니다. 여러 컨트롤러를 동시에 실행하며 각 컨트롤러는 클러스터의 특정 측면을 관리합니다. 클러스터의 상태를 지속적으로 모니터링하고 이벤트에 반응함으로써 컨트롤러 관리자는 원하는 상태가 적용되고 리소스가 효율적으로 활용되며 클러스터가 오류 및 기타 예기치 않은 이벤트에 대한 복원력을 유지하도록 합니다.
   
   
5. kube-proxy
    kube-proxy는 Kubernetes 클러스터의 각 작업자 노드에서 실행되는 중요한 구성 요소로, 서비스와 포드 간의 적절한 네트워크 통신을 보장합니다. 로드 밸런싱 및 서비스 검색을 달성하기 위해 네트워크 규칙을 유지하고 연결을 프록싱하여 Kubernetes Service 개념의 일부를 구현하는 일을 담당합니다.
   
   kube-proxy는 각 작업자 노드에서 부하 분산, 서비스 검색 및 네트워크 규칙 유지 관리를 담당하는 Kubernetes 네트워킹의 필수 구성 요소입니다. kube-proxy는 서비스와 포드 간의 네트워크 통신을 관리하여 클러스터가 효율적이고 안정적으로 작동하도록 합니다.
   
   
6. Kubelet
   kubelet은 Kubernetes 클러스터의 각 노드에서 실행되는 중요한 구성 요소로, 컨테이너가 포드 내에서 예상대로 실행되도록 하는 역할을 합니다. 컨트롤 플레인과 통신하고 노드에서 컨테이너의 수명 주기를 관리하는 기본 노드 에이전트 역할을 합니다.
   
   kubelet은 각 노드에서 실행되는 필수 구성 요소로, 컨테이너의 수명 주기를 관리하고 포드 내에서 예상대로 작동하도록 합니다. kubelet은 상태 확인을 수행하고, 리소스를 관리하고, 컨트롤 플레인과 통신함으로써 Kubernetes 클러스터의 안정성과 효율성을 유지하는 데 도움이 됩니다.

구성 요소 내 통신

쿠버네티스 시스템 구성 요소는 오직 API 서버하고만 통신하게 됩니다. 즉, 서로 직접 통신은 불가능합니다. 위 그림에서 알 수 있듯이, etcd와 통신하기 위해서는 API 서버를 꼭 거쳐야합니다. 따라서 다른 구성 요소는 API 서버로 클러스터 상태를 변경하게 됩니다.

위 사진을 보면 알 수 있듯이 API서버와 다른 구성 요소 사이의 통신은 대부분 다른 구성 요소에서 시작합니다. 하지만 다음 몇가지 경우에서는 API 서버가 Kubelet에 접속하게 됩니다.

1. kubectl을 사용해 log를 가져오는 경우
2. kubectl attach로 실행 중인 컨테이너에 연결할 때
3. kubectl port-foward를 실행할 때

각 구성 요소의 인스턴스 실행 방식 차이

각 컨트롤 플레인 구성 요소 인스턴스를 둘 이상 실행해 가용성을 높일 수 있습니다. 이 때 etcd, API서버와 스케줄러, 컨트롤러 매니저는 약간의 차이가 있습니다.

• etcd, API 서버 : 여러 인스턴스를 동시에 활성화해 작업을 병렬로 수행할 수 있습니다.
• 스케줄러, 컨트롤러 매니저 : 여러 인스턴스를 실행가능 하지만 하나의 인스턴스만 활성화 되고 나머지는 대기 상태에 들어갑니다.

구성 요소 실행 방법

먼저 시스템에 직접 배포하거나 파드로 실행하는 것은 마스터에서 가능합니다. 하지만 kube-proxy의 경우 마스터가 아니더라도 이것이 가능합니다. 이러한 특징은 kubelet에 대해 알고나면 이해가 되리라 생각됩니다.

kubelet은 항상 일반 시스템 구성 요소로 실행되는 유일한 구성 요소이며, kubelet이 다른 구성 요소를 파드로 실행하게 됩니다. 컨트롤 플레인 구성 요소를 파드로 실행하기 위해 kubelet도 마스터 노드에 배포 됩니다. 위 사진에서 보이는 것처럼 모든 컨트롤 플레인 구성 요소는 마스터 노드에서 파드로 실행되고 있는데, 두 개의 워커 노드는 kube-proxy를 실행해 파드를 위한 오버레이 네트워크를 제공하게 됨으로 직접 배포나 파드 실행이 가능하게 되는 것 입니다.

Flannel 파드도 kube-proxy와 같은 작용을 하는데 이 내용은 다음에 다루도록 하겠습니다. 다음 포스팅에서는 기본 구성요소인 파드(pod)에 대해 먼저 다루고, 이후에 Docker에 대해서 조금더 살펴보고 오늘 다뤘던 각 구성요소의 특징과 기능들을 하나씩 잘근잘근 씹어먹어 보겠습니다.

목차

1. 마스터 노드(컨트롤 플레인)
2. 워커 노드
3. 애드온

마스터 노드(컨트롤 플레인)

 컨트롤 플레인은 클러스터를 제어하고 작동시킵니다. 즉, 마스터 노드는 전체 쿠버네티스 시스템을 제어하고 관리하는 쿠버네티스 컨트롤 플레인을 실행한다고 말할 수 있습니다. 하나의 마스터 노드에서 실행하거나 여러 노드로 분할되고 복제돼 고가용성을 보장할 수 있는 여러 구성 요소로 구성됩니다.

1. 구성 요소
   
   • etc 분산 저장 스토리지
   • API 서버
   • 스케줄러
   • 컨트롤러 매니저
     
     
   컨트롤 플레인의 구성 요소는 클러스터 상태를 유지하고 제어하지만 애플리케이션을 실행하지는 않습니다. 이는 노드에 의해 이루어집니다.
   
   
2. 역할
   • 클러스터 상태 관리
     마스터 노드는 노드, 포드 및 서비스를 포함하여 클러스터의 모든 리소스 상태를 추적합니다.
     
     
   • 예약
     마스터 노드는 리소스 가용성 및 사용자 정의 정책을 기반으로 클러스터의 특정 노드에서 실행되도록 Pod(Kubernetes에서 배포 가능한 가장 작은 단위) 예약을 담당합니다.
     
     
   • 확장
     마스터 노드는 수요에 따라 클러스터에서 실행 중인 포드 수를 자동으로 확장 또는 축소할 수 있습니다.
     
     
   • 배포 업데이트 및 롤백
     마스터 노드는 배포 업데이트 및 롤백을 처리하여 애플리케이션 가동 중지 시간이 없도록 합니다.
     
     
   • 클러스터 전체 네트워킹 관리
     마스터 노드는 클러스터의 노드, 포드 및 서비스 간의 네트워크 연결을 설정하고 관리합니다.
3. 주요 기능
   • 고가용성
     컨트롤 플레인의 가용성을 보장하기 위해 Kubernetes는 고가용성 구성에서 여러 마스터 노드 실행을 지원합니다. 이렇게 하면 하나의 마스터 노드가 실패하면 다른 마스터 노드가 대신할 수 있습니다.
     
     
   • 확장성
     Kubernetes 마스터 노드는 수천 개의 노드와 수만 개의 포드가 있는 대규모 클러스터를 처리할 수 있습니다.
     
     
   • 보안
     마스터 노드는 클러스터에 대한 액세스를 인증하고 승인하여 인증된 사용자만 특정 작업을 수행할 수 있도록 합니다.
     
     
   • 사용자 정의 가능성
     Kubernetes는 고도로 사용자 정의가 가능하므로 사용자가 클러스터 작동 방식에 대한 자체 정책 및 구성을 정의할 수 있습니다.

워커 노드

워커 노드는 컨테이너화된 애플리케이션을 실행하는 시스템입니다. 애플리케이션을 실행하고 모니터링하며 애플리케이션에 서비스를 제공하는 작업은 다음 구성 요소에 의해 수행됩니다.

1. 구성요소
   
   • 컨테이너 런타임(Docker, rkt 등)
   • Kubelet(API 서버와 통신하고 노드의 컨테이너를 관리)
   • 쿠버네티스 서비스 프록시(애플리케이션 구성 요소 간에 네트워크 트래픽을 로드밸런싱)
   워커 또는 미니언 노드라고도 하는 Kubernetes 워커 노드는 Kubernetes 클러스터에서 실제 애플리케이션 및 워크로드를 실행하는 작업자 시스템입니다. 이러한 노드는 마스터 노드로부터 명령을 받고 할당된 작업을 실행합니다. Kubernetes 클러스터에서 워커 노드는 애플리케이션 또는 서비스를 구성하는 컨테이너 실행을 담당합니다.
   
   
2. 역할
   • Pod 실행
     작업자 노드의 기본 기능은 Kubernetes에서 배포 가능한 가장 작은 단위인 Pod를 실행하는 것입니다. 포드는 동일한 네트워크 네임스페이스를 공유하는 하나 이상의 컨테이너를 포함할 수 있으므로 localhost를 사용하여 서로 통신할 수 있습니다.
     
     
   • 컨테이너 관리
     작업자 노드는 필요에 따라 컨테이너 시작, 중지 및 다시 시작을 포함하여 컨테이너의 수명 주기 관리를 담당합니다.
     
     
   • 네트워킹
     작업자 노드는 IP 주소 할당 및 네트워크에 서비스 노출을 포함하여 실행 중인 컨테이너에서 들어오고 나가는 네트워크 트래픽을 처리합니다.
     
     
   • 상태 확인
     작업자 노드는 실행 중인 컨테이너에서 상태 확인을 수행하여 예상대로 실행되고 있는지 확인합니다. 컨테이너가 실패하면 작업자 노드는 다시 시작하려고 시도합니다.
     
     
   • 리소스 관리
     작업자 노드는 실행 중인 컨테이너에 대한 CPU, 메모리 및 스토리지를 포함한 리소스 할당을 관리합니다.
3. 주요 기능
   • 확장성
     Kubernetes 작업자 노드는 수요에 따라 확장 또는 축소할 수 있으므로 애플리케이션을 효율적이고 비용 효율적으로 실행할 수 있습니다.
     
     
   • 유연성
     Kubernetes 작업자 노드는 물리적 서버, 가상 머신 및 클라우드 인스턴스를 비롯한 다양한 플랫폼에서 실행할 수 있습니다.
     
     
   • 내결함성
     Kubernetes 작업자 노드는 고가용성을 위해 구성할 수 있으므로 하나 이상의 노드가 실패하더라도 애플리케이션이 계속 실행될 수 있습니다.
     
     
   • 사용자 지정 가능성
     Kubernetes는 작업자 노드에 대한 광범위한 구성 옵션을 제공하여 사용자가 특정 워크로드에 대한 리소스 및 설정을 미세 조정할 수 있도록 합니다.

애드온

Kubernetes 애드온은 Kubernetes의 기능을 향상하고 컨테이너화된 애플리케이션을 보다 쉽게 ​​관리하고 배포할 수 있도록 하는 다양한 특징과 기능을 제공합니다. 마스터 노드와 워커  노드에서 설명한 구성 외에도 클러스터에서 원활히 기능을 수행하기 위해서는 다음과 같은 요소들이 추가로 필요합니다. 이외에도 다양한 애드온이 있지만, 다음에 기회가 되면 다루어 보도록 하겠습니다.

1. 쿠버네티스 DNS 서버
2. 대시보드
3. 인그레스 컨트롤러
4. 힙스터
5. 컨테이너 네트워크 인터페이스

오늘은 쿠버네티스의 구조에 대해 알아보았습니다. 원래는 주요 단어들에 대해 설명하려 했으나, 내용이 생각보다 길어 다음에 따로 다루게 되었습니다. 조만간 이론 정리와 함께 실습 자료도 올릴 수 있도록 노력해보겠습니다.