- 컨테이너
- 도커(사실상 표준)
- 컨테이너 관리
- 쿠버네티스, 스웜모드: 쿠버네티스가 압도적.
- 개발 환경 구성 및 배포 자동화
- 젠킨스: CI/CD 지원. 개발한 프로그램 빌드, 테스트, 패키지화, 배포 단계 모두 자동화
- 모니터링
- 프로메테우스, 그라파나: 프로메테우스는 상태 데이터를 수집하고 그라파나는 수집한 데이터를 시각화. 중앙 모니터링. 컨테이너로 패키징 돼 동작하며 최소한의 자원으로 쿠버네티스 클러스터의 상태를 시각화
k8s는 모든 기능을 객체화 하였다.
k8s에서는 서비스 배포의 최소단위가 컨테이너가 아니라 pod이다.
- pod: 1 개 이상의 컨테이너 집합
pod는 서비스 위에서 작동한다. pod 만으로 연결이 되지 않고 서비스(오브젝트)에서 제공하는 node port, RB를 사용하여 연결 할 수 있다.
pod에서 스토리지를 사용하려면 PV, PVC와 같은 객체를 따로 만들어야 한다.- helm(헬름)은 k8s 환경에서 포드, 서비스, 컨피그맵, 시크릿, PV/PVC 등을 하나하나 설치하는 방법이 아닌 일종의 패키지 형식으로 간단히 설치하는 방법을 제공한다. 마치 CentOS에서 패키지를 손쉽게 dnf 또는 yum을 이용하여 배포하는 것과 비슷한 원리이다.
- swarm mode: manager(worker), worker1~worker3(worker)
k8s: master, worker1~3(노드라고 부름)- k8s에서는 모든 오브젝트(Pod, Replicaset, Deployment, service, configmap/secret, ingress, pv, pvc)는 yml 파일 형태로 작성하여 배포가 가능하다. 이를 메니페스트 파일이라 부른다. 물론 명령을 통해서도 배포는 가능하다. 하지만 재사용 등을 고려했을 때 파일 작성을 추천한다.
- 퍼블릭 클라우드 업체에서 제공하는 EKS 등
- OpenShift 같은 플랫폼에서 제공하는 설치형 쿠버네티스 (비싸다)
- kubeadm, kops와 같은 쿠버네티스를 자동으로 구성해주는 솔루션 사용. kubeadm은 사용자가 변경하기도 수월하고, 온프레미스와 클라우드를 모두 지원한다. 구성형 쿠버네티스
kubectl: 쿠버네티스 클러스터에 명령을 내리는 역할. 다른 구성요소와 다르게 바로 실행되는 명령 형태인 바이너리로 배포되기 때문에 마스터 노드에 있을 필요는 없지만 통상적으로 API 서버와 주로 통신하므로 마스터 노드에 구성.
API 서버: 쿠버네티스 클러스터의 중심 역할을 하는 통로. 주로 상태 값을 저장하는 etcd와 통신하지만, 그 밖의 요소들 또한 API 서버를 중심에 두고 통신.
etcd: 구성 요소들의 상태 값이 모두 저장되는 곳. etcd 정도만 백업되어 있으면
컨트롤러 매니저: 쿠버네티스 클러스터의 오브젝트 상태를 관리.
스케줄러: 노드의 상태와 자원, 레이블 요구 조건 등을 고려해 파드를 어떤 워커 노드에 생성할 것인지를 결정하고 할당한다.
- kubelet파드의 구성 내용을 받아서 컨테이너 런타임으로 전달하고, 파드 안의 컨테이너들이 정상적으로 작동하는지 모니터링 한다.
- 컨테이너 런타임(CRI): 파드를 이루는 컨테이너의 실행을 담당. 파드 안에서 다양한 종류의 컨테이너가 문제 없이 작동하게 만드는 표준 인터페이스.
- Pod
- 한 개 이상의 컨테이너로 단일 목적의 일을 하기 위해서 모인 단위. - 애플리케이션의 최소 단위
- 일반적으로 한 개의 주 컨테이너와 다른 한 개의 보조 컨테이너로 연결된다. 보조 컨테이너는 side-car 라고 부르며 주로 주 컨테이너를 모니터링하거나 로그 수집등에 활용된다.
- 포드내의 컨테이너는 별로의 노드로 분리되지 않는다.
- 네트워크 플러그인: pod간 overlay 통신을 위한 내부 플러그인
- CoreDNS: 노드 내에 있는 CoreDNS는 각 포드별로 이름을 부여하고 해당 이름에 대한 IP 정보를 보관한다. 포드 간 통신시 각 포드의 IP 정보를 확인할 필요없이 이름으로 접속할 수 있게 된다.
Reference