(Kubernetes pod to local 파일 복사 / Kubernetes container to local)
그런데 K8S 버그?로 에러메시지가 게속 떠서 안 되고 있는 줄 알았는데,
잘 되고 있더라!!! ㅎㅎ 그래도 나처럼 또 헤매고 있을 누군가에게 도움이 되기 위해!
우선, kubectl cp -h 라고 치면 다음과 같이 나온다.
$ kubectl cp -h
# !!!Important Note!!!
# Requires that the 'tar' binary is present in your container
# image. If 'tar' is not present, 'kubectl cp' will fail.
# Copy /tmp/foo_dir local directory to /tmp/bar_dir in a remote pod in the default namespace
kubectl cp /tmp/foo_dir <some-pod>:/tmp/bar_dir
# Copy /tmp/foo local file to /tmp/bar in a remote pod in a specific container
kubectl cp /tmp/foo <some-pod>:/tmp/bar -c <specific-container>
# Copy /tmp/foo local file to /tmp/bar in a remote pod in namespace <some-namespace>
kubectl cp /tmp/foo <some-namespace>/<some-pod>:/tmp/bar
# Copy /tmp/foo from a remote pod to /tmp/bar locally
kubectl cp <some-namespace>/<some-pod>:/tmp/foo /tmp/bar
ex) 노드가 죽거나 컨테이너 응답 X 경우, 자동으로 새로운 컨테이너를 띄우거나 자동으로 죽임 (선언한 처음 그대로의 상태를 계속해서 유지)
클러스터
가상 네트워크를 통해 통신하기 때문에 하나의 서버에 있는 것처럼 관리할 수 있음
서비스 디스커버리
서로 다 서비스를 쉽게 찾고 통신
스케줄링과 축출(Eviction)
스케쥴링
어떤 서버에 컨테이너를 띄울까 고민하지 않아도 쿠버네티스가 조건에 맞는 노드를 찾아서 컨테이너를 배치
kube-scheduler
쿠버네티스의 기본 스케줄러, 컨트롤 플레인의 일부로 실행 원하거나 필요에 따라 자체 스케줄링 컴포넌트를 만들고 대신 사용할 수 있도록 설계
마스터와 노드
클러스터
여러 대의 컴퓨터가 모여서 같은 목적으로 수행되는 컴퓨터들의 집합
마스터
마스터
클러스터 전체를 관리하는 컨트롤러로서 마스터가 존재
마스터에는 Kube-api-server, Kube-controller-manager, Kube-scheduler, Cloud-controller-manager, etcd 등의 컴포넌트가 실행
노드
컨테이너가 배포되는 물리적인 머신
cloud-contorlleromanager
: 오픈 클라우드와 혼합되어있을 때 사용,, (BI_PS팀에서는 잘 사용 X)
실제 컨테이너를 생성해야하니, pod를 생성하고 네트워크,볼륨을 설정 실제 컨테이너를 생성하는 서버 = 노예 서버 (GPU 전용 노드 : GPU를 사용하는 서비스만 띄울 수 있게끔 label 에서 설정, 기본은 무작위)
kubelet
: 클러스터 내 모든 노드로 배포되는 Agent ( 노예 관리자) Node 에 할당된 Pod 생명 주기, 주기적으로 / trouble shooting 진행 시, kubelet 많이 확인
kube-proxy
: 네트워크만 관리 , 컨트롤플레인노드에도 있음 (pod간의 네트워크 관리)
object
: 상태를 관리하기 위한 대상, Basic Object와 컨트롤 오브젝트로 분류
namespace
: 논리적 구분단위 이지만, 다른 namespace 간 Pod 의 통신이 가능 서비스 별로 ns(namespace)를 나눌 수 있음
kubectl get ns
kubectl get pods -n 이름
pod
: 서비스의 가장 기본적인 단위 (컨테이너을 포함한 상위 개념)
pod 안 컨테이너 특징 : 네트워크 환경과 디스크를 공유
pod 안에 yaml 형식에 잘 정리해주면, 디스크나 통신을 공유할 수 있음
service
컨테이너가 항상 살아있는 것은 아님, 컨테이너가 장애로 죽을 때, 서버가 다운이 되면 컨테이너가 죽기 때문에 파드가 사라짐 - 다시 재기동되면 그 노드에 뜰 수도 있고, 다른 노드에 띄울 수도 있음 - 다른 노드에 띄우면 아이피가 바뀜. / 아이피바뀜을 예방하기 위해 파드들의 서비스를 고정적으로 관리하는 서비스를 이용 대부분의 파드를 할 때, 서비스도 같이 생성
서비스 타입
클러스터아이피 : 자기들끼리만 소통하는 파드들을 사용할 때 아이피를 고정시켜줌
노드 포트 : 클러스트 내 모든 노드의 지정된 포트를 모두 뚫어주는 방식 모든 노드의 지정된 포트를 할당하는 방식
노드 밸런서 : 특정 IP 를 이용하여 외부에서 접근 가능하도록 함 ( IP 여분이 필요) 대부분의 튜토리얼은 웹서버 실습이 많으므로, 노드 밸런서를 사용하는 경우가 많음 노드 포트의 확장이므로 노드포트도 적용
external name
: 외부의 서비스를 kubernetes 내부에서 호출하고자 할 때 사용 ( 잘 사용 X )
Volume
container 재시작에 상관없이 파일을 영구적으로 저장해야하는 스토리지
Pod 내 Container 들은 해당 디스크를 공유하여 사용 가능
emptyDir
Pod 와 하께 생성하고 사라지는 임시 볼륨
HostPath
해당 노드의 디스크 경로를 Pod에 마운트하여 사용하는 방식
PV / PVC (pod와는 별개의 쿠버네티스만의 독특한 외장하드 같은 개념)
Pod가 죽든말든 PV가 삭제되지 않는 이상 데이터는 영원함!!!!! (yaml로 설정 가능)
PV : 볼륨 자체, 저장소
PVC : 요청, 이 PV를 얼마만큼 쓰겠다, 종류는 뭘로 하겠다라고 요청을 하는 추상화된 개념
예시 kubectl get pv kubectl get pvc -n hyperdata kg pvc - n hyperdata -o yaml
storageclass
: 동적으로 프로비저닝하는 다루는 객체 실제 노드에 있는 저장된 데이터를 이용할 수 있고, 영구적으로 저장하고 싶거나 여러 파드들과 데이터들을 공유하고 있을 때 pv와 pvc를 사용
예시 kubectl apply -f pvc-db.yaml kg pvc -n hyperdata
admin
: 실제 관리자, PV를 만들어줌, yaml을 통해서 사용자에게 배포
사용자가 어드민이 만들어준 PV를 사용 (1대1 매핑, 하나의 PV는 하나의 PVC만 물림)
rook-ceph
: 하이퍼클라우드에서 사용하는 PV는 모두 rook-ceph 기반으로 만들어짐. (분산 저장소)
