http://likefree.tistory.com/19
쿠버네티스와 마이그로서비스 아키텍쳐 - https://www.youtube.com/watch?v=xdqOxF2JqwU
쿠버네티스(Kubernetes)란?
- 쿠버네티스를 이해하기 이전에 먼저 컨테이너 운영환경에 대해서 이해를 해야한다.
컨테이너 운영환경 중 구글에서 개발했으며 가장 널리 사용되는 솔루션이다
중요한 점은 벤더 또는 플랫폼에 종속되지 않아 Public Cloud(구글, AWS, Azure)에도 사용이 가능하며
Private Cloud(OpenStack 등) 또는 베어메탈(가상화 환경을 사용하지 않는 일반 서버 하드웨어)에도 배포가 가능하기 때문에
하이브리드 클라우드 솔루션으로 많이 각광 받고 있다.
- 다수의 컨테이너를 다수의 노드에 적절하게 분산 실행하고 실행상태로 유지하며 스케일 인 아웃을 지원한다
컨테이너 운영환경?
- 적은 수의 컨테이너를 배포한다면 VM이나 하드웨어에 직접 배포하면 되지만 VM이나 하드웨어의 수가 많아지고
컨테이너의 수가 많아지면, 이 컨테이너를 어디에 배포해야 하는지에 대한 결정이 필요하다
예를 들어 16 CPU 32GB 메모리 VM들에 컨테이너를 배포할 때 컨테이너 사이즈가 2CPU, 3CPU, 8CPU등 다양할 수 있기 때문에
자원을 최적으로 사용하기 위해 적절한 위치에 배포를 해야한다. 이러한 컨테이너를 적절한 서버에 배포하는 것을 스케쥴링 이라 한다.
이러한 스케쥴링 뿐만 아니라 각 컨테이너들의 상태를 체크하고 이를 재기동하며 로드밸런싱 및 모니터링 등의 종합관리를
해주는 환경이 필요한데 이를 컨테이너 운영환경이라고 한다.
클러스터 구조 마스터와 노드
- 쿠버네티스를 이해하기 위해서는 클러스터 구조를 이해할 필요가 있다
클러스터의 구조는 아래 그림과 같이 간단하다
그림 출처 - https://blog.2dal.com/2018/02/28/kubernetes-intro/
1. 마스터
- API Server, Controller Manager, Scheduler, etcd로 구성된다
- 클러스터 전체를 관리하는 컨트롤러
- 아래 그림과 같이 관리자는 Master의 API Server를 통해 K8s를 관리하며
모든 컴포넌트들은 API Server을 통해 서로 통신한다
1) API Server
- K8s의 내부의 모든 컴포넌트들이 서로를 호출하기 위해 사용되는 컴포넌트이다
- K8s는 서로가 직접 연결되어 있지 않고 API Server를 통해 통신한다
- 각각의 컴포넌트들은 API Server를 Watch하고 있다가 자신에 대한 변경사항이 생기면 업데이트하는 구조이다.
2) Controller Manager
- K8s의 ReplicaSet, Deployment등의 Controller를 관리 및 적절한 노드에 할당
- 각 Controller들에게 Pod의 복제/배포 명령을 수행한다
3) Scheduler
- Pod를 어떤 Node에서 실행할지를 결정한다
- Node에 배치된 Pod는 각 노드의 Kubelet에 의해 컨테이너로 생성된다.
4) etcd
- 분산 키/값 저장소로 클러스터 설정 및 현재 상태를 저장한다
(클러스터의 각 노드, 노드에서 동작중인 Pod의 모든 상태)
2. 노드
- 노드는 Kubelet, cAdvisor, Kube-Proxy, Pod로 구성된다
- 컨테이너가 배포되는 가상머신 또는 물리적인 서버
- 아래 그림과 같이 노드는 API Server의 요청을 Kubelet을 통해 수행한다
1) Kubelet
- Node에 배포되는 Agent로 API Server와 통신하며 노드가 수행할 명령을 받아 수행하며
Node의 상태를 마스터로 전달하는 역할을 수행한다.
2) Kube Proxy
- 노드로 오는 트래픽을 적절한 컨테이너로 프록시하며, 노드와 마스터간의 네트워크 통신을 관리한다
3) cAdvisor
- 노드의 모니터링 Agent로 노드에서 가동되는 컨테이너들의 상태정보를 수집하여 마스터의 API Server로 전달한다.
구성요소
오브젝트
- 쿠버네티스는 가장 기본적인 구성단위인 Basic Object와,
이 Basic Oject들을 생성 및 관리하는 추가 기능을 가진 Controller
그리고 이러한 Object의 Spec(설정) 및 메타정보들로 이루어 진다.
Object Spec(오브젝트 스펙)
- 각각의 Object들은 모두 오브젝트들의 특성(설정정보)을 기술한 Object Spec으로 정의가 되고
CLI를 통해 Object 생성시 인자로 전달하여 정의를 하거나 Yaml 이나 Json 파일로 Spec(설정정보)를 정의할 수 있다.
Basic Object(기본 오브젝트)
- 쿠버네티스에 의해서 배포 및 관리되는 가장 기본적인 오브젝트는 컨테이너화되어 배포되는 애플리케이션의 워크로드를
기술하는 오브젝트로 아래의 4가지로 구분된다.
1. Pod
- 쿠버네티스는 하나의 컨테이너를 개별적으로 배포하는 것이 아닌 Pod 단위로 배포한다
- 쿠버네티스에서 가장 기본적인 배포 단위로 하나 이상의 컨테이너를 포함하는 단위이다.
- 일반적으로 1 Pod 1 Contanier 이다.
특징
- Pod 내의 컨테이너들은 IP, Port를 공유한다.
예를 들어 컨테이너 A가 8080 Port를 사용하고 B가 80으로 배포되었을 때
A->B 는 localhost:80 , B->A는 localhost:8080으로 호출이 가능하다.
(두 개의 컨테이너가 하나의 Pod를 통해서 배포되었을 때, localhost를 통해서 통신이 가능하다!)
- Pod가 재시작되면 IP가 변경되며
Pod내의 컨테이너들의 로컬디스크의 내용이 사라진다
- 서로 다른 컨테이너가 Volume을 공유한다
*Pod의 Object spec(오브젝트 스펙)
- 위에서 각각의 오브젝트들은 Object Spec에 의해 정의가 된다고 했다 아래는 Pod의 Object Spec이다
apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 8090
apiVersion : 이 스크립트를 실행하기 위한 쿠버네티스의 API 버젼
kind : Object의 종류
metadata : Object의 각종 메타데이터
spec : 상세 스펙을 정의하는데 pod는 하나 이상의 컨테이너를 포함하므로 containers 속성이 있다
container : 이름은 nginx, 도커이미지는 nginx:1.7.9, 컨테이너포트의 8090을 오픈한다.
2. Volume
- pod 과 lifecycle이 같다
영구적인 자료를 저장하기 위해서는 PersistentVolume(볼륨)을 사용해야 한다
- Volume(볼륨)은 컨테이너의 외장디스크격으로 생각하면 된다. Pod가 기동될때 컨테이너에 마운트하여 사용한다.
- 쿠버네티스는 다양한 외장 디스크를 제공한다 iSCSI나 NFS와 같은 Onpremiss기반의 외장 스토리지 이외에
클라우드 외장 스토리지인 AWS EBS, Google PD 그리고 github, 등의 오픈소스 기반 외장스토리지 서비스를 지원한다.
3. Service
- Label Selector로 Pod를 선택하여 하나의 Endpoint로 노출시킨다
- 프리버젼을 사용하게 되면 WorkerNode의 NodePort로 밖에 접근할 방법이 없다.
종류:
ClusterIP, NodePort, LoadBalancer, ExternalName
- Pod와 Volume을 이용하여 컨테이너들을 정의한 후에 Pod를 서비스로써 제공할 때
일반적으로 하나의 Pod로 서비스하는 경우는 드물고 여러개의 Pod를 서비스하며 이를 로드밸런서를 이용해
하나의 IP와 포트로 묶어서 서비스를 제공한다.
- Pod의 경우 동적으로 생성이 되며 장애 발생시 자동으로 리스타트 되며 그 IP가 바뀌기 때문에 로드밸런서에서
Pod의 목록을 지정할 때 IP를 이용하는 것은 어렵다.
그래서 사용하는 것이 라벨(Label)과 Label Selector(라벨셀렉터) 이다.
- 서비스를 정의할 때 어떤 Pod들을 Service로 묶을 것인지를 정의하는데 이를 Label Selector라고 한다
각 Pod를 생성할 때 Object Spec의 metadata 부분에 Pod에서 사용할 라벨(Label)을 정의할 수 있다.
Service는 Label Selector(라벨 셀렉터)에서 특정 라벨을 가진 Pod만을 선택하여 Service에 묶는다
아래 그림은 Service가 Label ="app:myapp" 인 Pod만을 골라내어 Service로 묶고 그 Pod간에만 로드밸런싱 하여
외부로의 서비스를 제공하는 그림이다.
*위 그림의 Service의 Object Spec
kind: Service
apiVersion: v1
metadata:
name: my-service
spec:
selector:
app: myapp
ports:
- protocol: TCP
port: 80
targetPort: 9376
kind : Basic Object의 종류가 service이므로
apiversion : 쿠버네티스의 API 버젼
metadata : 서비스의 이름을 my-service로 지정
spec : 서비스에 대한 스펙
selector : label이 "app:myapp"인 Pod 만을 선택하여 서비스에서 서비스를 제공
port 는 80/TPC로 서비스를 하되 컨테이너의 9376로 포워딩하여 서비스를 제공한다
4.
Controller(컨트롤러)
1. Replication Controller
- Pod를 지정된 수로 유지 및 관리하는 역할
2. Replica Set
- Replication Controller의 새버전이다
3. Deployment
- Replication Set의 작성과 갱신을 하는 것.
- blue/green deployment 등
'Infra > kubernetes' 카테고리의 다른 글
| Kubernetes - pod 관련 명령어 (0) | 2019.01.31 |
|---|---|
| Kubernetes - pod error 정리 - 추가중 (0) | 2019.01.31 |
| Kubernetes - Kubernetes 사용법 (0) | 2019.01.27 |
| Kubernetes - kubernetes 설치 및 설정 (6) | 2019.01.27 |
