0부터 시작하는 Kubernetes 공부 - Kubernetes 정리

Kubernetes Node 의 Role

• master : master / controller
• node ( worker ) : none

Kubernetes Cluster 내부 구조

• 출처 : https://seongjin.me/kubernetes-cluster-components/

• api-server : 컨트롤 플레인의 프론트 엔트. 외부 사용자와 상호 통신

• key value store(etcd) : 클러스터 데이터베이스를 백업하기 위해 사용하는 데이터베이스. 마스터는 노드, pod, 컨테이너들의 상태 정보를 파악하기 위해 etcd 에게 쿼리한다. DB 형태의 스토리지이다. 모든 상황에 대한 정보는 etcd 에 저장된다

• 컨트롤러 매니저 : 실제로 클러스터를 실행, 하나의 컨트롤러는 스케줄러를 참조하여 정확한 수의 포드를 실행. 포드에 문제가 발생하면 다른 컨트롤러가 이를 감지하고 대응. 서비스를 포드에 연결하므로 요청이 적절한 엔트포인트로 이동. 계정 및 API 액세스 토큰 생성

• 스케줄러 : 클러스터 상태가 양호한가? 새 컨테이너가 필요하다면 어디에 배치할까? CPU 또는 메모리와 같은 포드의 리소스 요구 사항과 함께 클러스터 상태 고려

  • 컨트롤러가 배치를 명령하고자 하면, 스케쥴러가 api server 를 통해 etcd 로 부터 클러스터 상태를 파악하여, 배치에 적절한 노드를 결정하고, 이를 api server 를 통해 컨트롤러에게 전해준다. 그러면, 컨트롤러는 해당 노드에 배치 명령을 내린다

• kubelet : 컨트롤에서 노드에 작업 요청시 kubelet 가 작업 실행

• kube-proxy : 각 컴퓨팅 노드에는 k8s 네트워킹 서비스가 용이하도록 네트워크 프락시인 kube-proxy 가 기능한다. 트래픽 자체를 전달하여 클러스터 내부 또는 외부의 네트워크 통신 처리

  • Pod 안의 컨테이너들은 외부 통신을 위해 proxy 를 사용한다. 즉, Pod 안의 컨테이너가 NFS 와 Bind 할 때, Proxy 를 통해서 외부에 나간다

• 퍼시스턴트 스토리지 : 사용자가 기본 스토리지 인프라에 관한 상세 정보를 몰라도 리소스 요청 가능

• CoreDNS : DNS 서비스를 제공하는 Deployment 로, POD 와 SERVICE 가 배포될 때, IP 주소 정보와 DOMAIN 이름을 자동으로 등록해 DOMAIN 이름으로 연결 가능하게 해준다

  p. 480

Pod 에 Volume Mount 하는 방법

정적인 방법

• NFS 볼륨을 Pod 에 직접 마운트하기

  • 개발자와 운영자가 1 명인 경우로, NFS, IscsI 가 무엇인지 알고 있는 사람이다

동적인 방법

• Volume 에 대한 정보를 정확히 알 수 없는 경우에는 PV / PVC 를 이용한다 ( Persistent Volume / Persistent Volume Claim )

• 제공할 수 있는 볼륨을 정의하여 PV Pool 에 담는다. PV 에는 용량 / Access Mode ( readwriteonce - 1:1 / readwritemany - 1:N - Shared ) / ReclaimPolicy ( PV 와 PVC 가 연결된 상태에서 해제되었다면, 생성된 PV 를 어떻게 처리할 것인지에 대한 정책 )

  ReclaimPolicy

  • Retain ( 남겨두기 - Default 정책이다 ) , Delete ( Data 포함하여 Volume 삭제 )

• Volume 요청에는 PVC 를 사용한다. 여기서는 Accessmode / 최소 용량 을 작성한다

K8S VS Swarm Mode

• Application 의 배포 단위

  • K8S 는 한 개 이상의 컨테이너로 구성된 POD 가 단위이다

    

    • POD 안의 컨테이너들은 POD 의 IP 를 공유하므로, 하나의 POD 에 다수의 웹 컨테이너를 배치하는 구조는 사용하지 않는다. 둘 다 80 PORT 를 사용하면, IP 를 공유하기에 사용하는 PORT 가 중복되기 때문이다. 그러므로 POD 는 보통 MAIN 컨테이너와 SIDE CAR 컨테이너로 구성한다

  • Swarm Mode 는 컨테이너가 단위이다

Object

p. 112

기본 Object

POD : K8S 에서 실행되는 최소 단위. 범용으로 사용할 때는 대부분 1 개의 POD 에 1 개의 컨테이너를 적용. 독립적인 공간과 IP 를 가진다

• POD 는 한 개 이상의 컨테이너로 단일 목적의 일을 하기 위해서 모인 단위이다. 언제라도 죽을 수 있다
• 예를 들어, Scale 을 조정한다거나 롤릴 업데이트와 같은 경우에는 기존 POD 를 죽이고, 새로운 POD 가 생성된다. 따라서 하나의 POD 에서 DATA 를 영구적으로 관리하는 것이 매우 어렵고, 특정 POD 로 지속적으로 접근하는 것도 사실상 거의 어렵다

  • Deployment 가 아닌 Stateful Set 을 이용하면 POD 의 상태를 유지할 수 있다

Namespace : 리소스를 구분하는 그룹, 작업 공간. 여러 프로젝트가 진행되는 경우, 별도의 Namespace 를 사용하여 프로젝트를 진행할 수 있다

• 클라우드의 특징 중 하나에는 멀티 테넌시가 있다. 이는 다수의 테넌트가 하나의 공간에 모여있는 것이다
• 멀티 테넌시 : 클라우드 컴퓨팅 에서는 서로 다른 고객이 서버 리소스를 나누어 사용하는 공유 호스팅을 멀티 테넌시 라고 부른다. 이는 하나의 물리적 공간을 다수의 테넌트가 사용하는 것이다. 이때, 테넌트 단위로 작업 공간을 분리한다 ( Tennent = Project = Namespace - 똑같은 서버의 리소스를 공유할 때, 이 작업 공간을 분리 시켜주는 것 )

  • 이와 반대 개념인 단일 테넌시가 있다. 단일 테넌시에서는 소프트웨어 인스턴스 또는 컴퓨터 시스템 하나에 최종 사용자 또는 사용자 그룹 하나만 있다

Volume : POD 생성시 사용할 수 있는 디렉토리를 제공하는데, POD 는 유동적이므로 이 디렉토리를 임시로 사용한다. 이를 Volume Object 를 통해 POD 가 사라지더라도 DATA 를 저장 및 보존이 가능한 디렉토리를 생성하여 사용할 수 있다

Service : POD 는 클러스터 내에서 유동적이기에 접속 정보가 고정적이지 않다. 이 POD 접속을 안정적으로 유지하기 위해 서비스를 통해 POD 를 내/외부로 연결시킨다

• Cluster IP, Node Port, LB 가 있다
• Node Port 서비스는 Port 중복이 불가능하다. 1 개의 NodePort 에 1 개의 Deployment 가 적용된다

그외 Object

Deployment : 기본 오브젝트 외의 오브젝트로, 기능들을 조합하고, 추가해서 구현한 오브젝트 이다. Deployment 는 버전 관리가 가능하다

• 이때, Rolling Update 시 Surge 와 Unavailable 을 설정할 수 있으며, 기본적으로 25% / 25% 로 정해진다

Ingress 앞에는 Ingress Controller 가 필요하다. Ingress Controller 로 트래픽이 들어오면, Ingress 를 참조하여 트래픽을 전달해준다

• Controller 는 앞에 자동으로 LB 서비스를 배치한다. 이 LB 서비스는 MetalLB 를 통해 외부 연결용 IP 를 할당 받을 수 있다. 이 할당된 IP 를 DNS 에 등록하여 사용한다
• 구조 : LB ---------- Ingress Controller ( 참조 - Ingress ) -------- NodePort SVC ----- POD

ConfigMap, Secret 은 둘 다 Pod 내에서는 Clear Text 로 보여진다. 단, Node 간 통신에서 Secret 의 Data 는 노출되지 않는다