쿠버네티스 용어 한줄 요약 정리

k8s

VM은 호스트OS-하이퍼바이저-게스트OS

컨테이너는 호스트OS-컨테이너런타임-컨테이너(=프로세스)

컨테이너 여러개 사용할때 문제 = 컨테이너 사이 통신 / 가용성 확보(부하분산) / 다중화 고민 / 가상머신에 장애가 생기면?

쿠버네티스 = 데이터 플레인(서비스 사이 네트워크 트래픽 관리하는 서비스 메시) 서버를 여러대 실행시켜, 가상 오케스트레이션 계층을 구축하고 거기에서 컨테이너가 동작한다.

그러면 컨테이너 그룹을 하나의 큰 머신 리소스로 추상화 가능.

컨트롤 플레인으로 어떤 머신에서 동작시킬지 / 정지시킬지 판단가능

파드 = 쿠버네티스 최소 단위. Pod 하나 안에서는 하나 이상의 컨테이너 동작 가능. 어떤 컨테이너 이미지 쓸 지 설정함

레플리카셋 = 파드를 얼마나 동작시킬지 관리.

디플로이먼트 = 배포 이력 관리. 롤백 쉽게 가능함

서비스 = 파드를 외부에 공개하기 위한 구조 제공 ex)로드밸런서

EKS : 쿠버네티스 가장 큰 장벽은 컨트롤 플레인 유지/운영임. 쿠버네티스는 컴포넌트들이 독립/비동기 동작하면서 전체를 구성해서 장애시 복구가 어려움. EKS는 이런 유지/운영을 AWS가 해주는 것임

VPC : 쿠버 클라우드에선 외부에서 파드로 엔드포인트 생성 안하면, 통신이 불가능함. VPC 내부 주소 대역을 사용할 수 있고, 클러스터ㅏ 외부와의 통신을 심리스하게(단순하게) 구현할 수 있음

IAM : 인증같은거임.

ELB : 전형적인 엔드포인트가 로드밸런서임. AWS의 로드밸런서 서비스가 ELB(elastic load balancing).

데이터플레인은 EC2와 파게이트 두개가 있음. EC2는 관리해야되지만 자유, 파게이트는 반대. 중간에 관리형 노드 그룹이 있음(EC2긴한데, 좀 다름)

---

가상화 인프라 환경 구성

컨테이너 인프라 환경은 컨테이너, 컨테이너 관리, 개발환경 구성 및 배포 자동화, 모니터링으로 구성됨

젠킨스는 CI/CD(지속적통합/지속적배포) 지원

프로메테우스는 상태데이터 수집, 그라파나로 수집한 데이터를 시각화

프로비저닝 = 시스템자원을 미리 할당/배치/배포 해두었다가, 필요할때 제공해줌

쿠버네티스로 컨테이너 인프라 환경 이해

오케스트레이션 = 복잡한 단계 관리, 요소들의 유기적 관계 미리 정의해 쉽게 사용할수 있는 서비스

IP 마스커레이드 = 커널에서 제공하는 NAT같은거

마스터 노드

kubectl = 쿠버 클러스터에 명령 내리는 역할.

api 서버는 중심 통로.

etcd(/etc + distributed) = 구성정보를 퍼트려 저장. 구성요소들 상태값 모두 저장. 그래서 etcd만 살아있으면 장애상황에서 복구 가능.

컨트롤러매니저 = 쿠버 클러스터의 모브젝트 상태 관리.

스케줄러 = 노드의 상태 고려해 파드를 어떤 워커 노드에 생성한지결정하고 할당

워커 노드

kubelet = 파트 구성내용 받아서 컨테이너 런타임으로 전달, 정상작동하나 모니터링

컨테이너 런타임

Pod : 단일 목적 단위.

기타

네트워크 플러그인 = 통신 위한거.

CoreDNS = DNS서버.

---

파드 배포 이후 사용자가 접속할때는 kube-proxy 같은걸 씀

k8s는 순서적 구조가 아니라 선언적인 시스템 구조임. 각 요소가 추구하는 상태(desired status)선언하면, 현재 상태(current status)와 맞는지 점검하고 맞추려고 함.

그래서 추구하는 상태를 API서버에 선언하면, 다른 요소들이 API서버와 비교하고 알아서 맞춤. 이 상태값을 보존하는게 etcd

kubectl은 아무데서나 가능함. 쿠버네티스 클러스터의 정보(API 서버 접속 정보)만 알 수 있다면.

kubelet은 파드 생성/상태관리/복구 담당하는 요소.

kubectl run은 파드를 만들고, kubectl create deployment는 디플로이먼트를 만듬. run은 단일 파드, 디플로이먼트는 관리 그룹 내에 파드가 생성됨.

네임스페이스 = 쿠버 클러스터에서 사용되는 리소스들을 구분해 관리하는 그룹. 기본적으로 default, kube-system, metallb-system이 기본으로 있음

볼륨 = 파드에서 사용할 수 있는 디렉터리. 파드가 사라지더라도 보존이 가능하게.

파드, 네임스페이스, 볼륨, 서비스 4가지가 기본 오브젝트

기본 오브젝트 말고 여러 기능을 조합해 구현 한 것들이 deployset, demonset, configmap, replicaset, pv, pvc 등 다른 오브젝트가 있음

디플로이먼트 = 파드+레플리카셋이라고 보면됨

K8S에서의 서비스 = 외부에서 쿠버 클러스터에 접속하는 방법.

가장 간단한 방법은 노드포트. 모든 노드의 특정 포트를 열어서 전달함.

인그레스 = 고유한 주소를 제공해 사용 목적에 따라 다른 응답 제공 가능, 트래픽에 대해 L4/L7 로드밸런서와 보안 인증서 처리

인그레스를 쓴다고 해도 인크레스 컨트롤러가 필요함. 인그레스 컨트롤러는 파드랑 직접 통신이 안돼서 노드포트/로드밸런서랑 연동되어야함.

온프레미스(Private)에서는 마땅히 로드밸런서가 구현되어있지 않음.

HPA(horizontal pod autoscaler) = 디플로이먼트의 파드 수를 사용자 수에 따라 유동적으로 관리

메트릭 서버 = 모니터링 도구

데몬셋 = 디플로이먼트의 replicas가 노드 수만큼 정해져 있는 형태. 노드 하나당 파다 하나만. 노드를 관리하는 파드라면 데몬셋으로 만드는게 효율적

컨피그맵 = 설적 목적 오브젝트

다양한 형태의 볼륨이 있음(emptydir, hostpath, downawrdAPI, configMap…)

PV와 PVC도 그중 하나임

쿠버는 필요할때 PVC(지속적으로사용가능한 볼륨 요청)를 요청해 사용함. PVC를 사용하려면 PV(지속적으로 사용 가능한 볼륨)으로 볼륨을 선언해야 함.

PV 종류로는 MFS, aws elastic block store….등이 있음

스테이트풀셋 = 파드가 만들어지는 이름과 순서를 예측해야 할 때. 주로 redis ,mongodb등 master-slave 구조 시스템에서 필요.

도커로 컨테이너 다루기

젠킨스로 지속적 통합과 배포 자동화

패키지 관리자 역할

• 패키지 검색 : (원격/로컬)저장소에서 패키지 검색
• 패키지 관리 : 저장소에서 패키지 정보확인하고 설치,삭제,업그레이드
• 의존성 관리 : 의존 소프트웨어 설치 관리
• 보안 관리 : 패키지의 checksum으로 감지

차트 = 다양한 요구 조건을 처리할 수 있는 패키지

프로메테우스과 그라파나로 컨테이너 인프라 환경 관리

cAdvisor = 구글이 만든 컨테이너 메트릭 수집 도구. 쿠버 클러스터 위에 배포된 여러 컨테이너가 사용하는 메트릭 정보 수집 후 가공해서 kublet에 전달

리소스 메트릭 파이프라인 = 메트릭 수집→통합→시각화 하는것 (메트릭 서버는 메모리에만 저장해서 보존이 안됨)

완전한 모니터링 파이프라인 = 리소스 메트릭 파이프라인의 통합에서 저장하는 과정 추가

프로메테우스

프로메테우스 서버 = 메트릭 수집해오는 수집기, 메트릭 저장하는 시계열DB, 저장된 데이터 질의/확인하는 웹UI.

노드 익스포터 = 시스템 메트릭 정보를 HTTP로 공개.

코버 스테이트 메트릭 = api서버로 쿠버 클러스터의 여러 메트릭 데이터 수집후, 프로메테우스가 원하는 형태로 변환해 공개하는 역할.

얼럿매니저 = 프로메테우스에 alert 규칙 설정.

푸시게이트웨이 = 배치와 스케줄 작업시 수행되는 일회성 작업들의 상태 저장하고 모아서 프로메테우스가 주기적으로 가져갈 수 있도록 공개.