인프런 > 초보를 위한 쿠버네티스 안내서를 통한 정리입니다.
쿠버네티스에서 사용하는 발음
쿠버네티스 소개
•
컨테이너화된 애플리케이션을 자동으로 배포, 스케일링 및 관리
•
컨테이너를 쉽게 관리하고 연결하기 위해 논리적인 단위로 그룹화 했다.
•
Google에서 15년간 경험을 토대로 최상의 아아디어와 방법들을 결합
쿠버네티스 데모
쿠버네티스 아키텍처(어떻게 구성이 되어 있는가?)
Desired State
•
쿠버네티스의 근간을 아우르는 시스템
아키텍처 도식화
•
Master : 체크하고 실행 하는 영역
•
Node : 실제 컨테이너가 실행되는 영역
•
API Server : 중간에 교통정리 하는 역할
•
etcd: 상태를 저장하고 조회하는 리스트
Master 상세
Etcd
•
모든 상태와 데이터를 저장
•
분산 시스템으로 구성하여 안정성을 높임(고가용성)
•
가볍고 빠르면서 정확하게 설계(일관성)
•
Key(directory)-Vale 형태로 데이터 저장
•
TTL(time to live), watch같은 부가 기능 제공
•
백업은 필수!
API server
•
상태를 바꾸거나 조회
•
etcd와 유일하게 통신하는 모듈
•
REST API 형태로 제공
•
권한을 체크하여 적절한 권한이 없을 경우 요청을 차단
•
관리자 요청 뿐 아니라 다양한 내부 모듈과 통신
•
수평으로 확장되도록 디자인
Scheduler
•
새로 생성된 Pod을 감지하고 실행할 노드를 선택
•
노드의 현재 상태와 Pod의 요구사항을 체크
◦
노드에 라벨을 부여
◦
ex) a-zon, b-zon, 또느 gpu-enabled,…
Controller
•
논리적으로 다앙한 컨트로러가 존재
◦
복제 컨트롤러
◦
노드 컨트롤러
◦
엔드포인트 컨트롤러….
•
끊임 없이 상태를 체크하고 원하는 상태를 유지
•
복잡성을 낮추기 위해 하나의 프로세스로 실행
조회흐름
Controller : →(정보조회)→ API Server : 정보 조회 권한 체크 →(정보 조회)→ etcd
etcd →(원하는 상태 변경)→ API server →(원하는 상태 변경)→ Controller:원하는 상태로 리소스 변경→(변경 사항 전달)→ API server : 정보 갱신 권한 체크 →(정보갱신)→etcd:정보갱신
스캐줄러와 수많은 컨트롤러가 etcd와 직접 통신하는게 아닌 API server를 통해 호출한다.
Node
•
노드에서 proxy와 Kublelet은 API Server와 통신한다.
•
설계가 마이크로소프트 아키텍처로 잘 되있는것을 알 수 있다.
kubelet
•
각 노드에서 실행
•
Pod을 실행/중지하고 상태를 체크
•
CRI (Container Runtime Interface)
◦
Docker
◦
Containerd
◦
CROI-O
◦
…
•
큐블릿이 컨테이너를 사용할 수 있도록 Pod으로 한번 더 감싼다.
proxy
•
네트워크 프록시와 부하 분산 역할
•
성능상의 이유로 별도의 프록시 프로그램 대신 iptables 또는 IPVS를 사용
•
프록시가 하는역할은 iptables 또는 IPVS에서 설정만 한다.
전반적인 쿠버네티스 구상도
쿠버네티스의 관리
Pod
•
쿠버네티스의 가장 작은 단위
◦
컨테이너를 배포하는 것이아니라 Pod를 배포하는 것이다.
•
각 팟마다 고유 IP를 할당
•
여러개의 컨테이너가 하나의 Pod에 속할 수 있음
•
포트를 로컬호스트에서 공유할 수 있다.
ReplicaSet
•
여러개의 Pod을 관리
•
신규 Pod을 생성하거나 기존 Pod을 제거하여 원하는 수(Replicas)를 유지
Deployment
•
배포 버전을 관리
•
내부적으로 ReplicaSet을 이용해서 버전 업을 할때 자연스럽게 한다.
•
배포를 하게 될 때 순간적으로 ReplicaSet을 한개 더 만들어서 version1과 version2를 만든다.
•
이후 한 리플리 카셋안에 있는 Pod을 한개씩 버전업을 해주면서 올린다.
다양한 Workload
•
DEAMON SET : 모든 노드에 꼭 1개씩 뜨기를 원할 때
•
STATEFUL SETS : 순서대로 팟을 실행 시키거나, 같은 볼륨을 계속 재활용 하고 싶다
•
JOB : 한번 실행하고 죽는 Pod
네트워크 - Service - ClusterIP
•
ClusterIP : Pod을 로드밸런서한 서비스 이다.
•
클러스터 내부에서 사용하는 프록시
•
클러스터 IP에 요청을 하게되면 자동으로 3개의 Pod중에 한개로 접근하게된다.
◦
사용하는이유
▪
Deployment나 Replicaset은 Pod이 업데이트 될 때 IP를 유지하면서 업데이트 되는 것이아니기 때문
▪
Pod이 죽고 새로운 Pod이 뜨는 개념 IP가 언제든지 사라졌다 변경되는게 자연스럽다.
▪
때문에 요청을 보낼때 Pod이 아닌 ClusterIP를 거쳐서 가게 된다.
Service - NodePort
•
클러스트 IP는 내부에서만 통신이 가능하다.
•
외부 브라우저에서는 접근이 불가능하다.
•
따라서 외부에서 접근하기 위해서 Node port라는 개념이 등장한다.
◦
노드에 포트가 생기고 해당하는 포트로 접근을 하게 되면 해당하는 요청이 ClusterIP에 접근하고 그다음 Pod으로 전달되는 과정이 생긴다.
Service - LoadBalancer
문제발생
•
1번 노드에 도메인을 연결 해놨는데, 해당하는 노드가 죽었을 시
•
2번 노드에 접근해야 되는데, 설정을 1번으로 해놓았기 때문에 브라우저로 접근 자체가 안된다.
해결방법
•
이를 방지하기 위해 노드포트 앞에 LoadBalancer를 설정해 놓는다.
◦
사용자는 LoadBalacncer에 요청 → NodePort → ClusterIP →Pod으로 실행된다.
Ingress
•
도메인 이름, 도메인 뒤에 붙는 Path에 따라서 내부에 있는 ClusterIP로 이동할 수 있다.
•
3개의 URL로 접근했을때 전부다 노드포트를 만들거나, 전부 LoadBalancer를 만들면 자원의 낭비가 심하다.
◦
때문에 Ingress 한개로 만들고 Ingress가 내부적으로 servier를 분기처리 해줄 수 있다.
일반적인 구성
쿠버네티스 API 호출
Pod 생성
•
팟을 생성시키고 싶을 때
•
Object Spec - YAML을 통해 작성한다.
Object Spec - YMAL 리플리카셋 호출
API 호출하기 정리
•
원하는상태(Desired state)를 다양한 오브젝트로(Object)로 정의(spec)하고 API 서버에 Ymal형식으로 전달