Kubernetes 스터디

Kubernetes 스터디

 

blog.mirapps.net/kube-intro/

쿠버네티스와 컨테이너기반 시스템 – Mir

쿠버네티스

컨테이너 런타임을 관리하는 오케스트레이션 도구

 

컨테이너

Hypervisor : CPU core, Memory, ... -> overhead

 

AWS :: EKS

 

 

 

---

쿠버네티스_스터디_발표자료.ppt

 

3p.

Application 설치

어플리케이션 : was 등을 의미

 

 

4p.

설정

디렉토리

환경변수

버전 ... 등 꼬일 수 있음

MSA

 

 

5p. VM

하이퍼바이저를 통해서 서버를 가상화하고 관리

다량의 서버를 각각 관리해야됨

복제도 가능함

 

 

6p. Docker

시스템 운영자들이 서비스에 대해 자세히 몰라도 올리고/내리고 작업을 쉽게 할 수 있음

설치가 쉽고

속도도 빠름

 

 

7p. 오케스트레이션

극단적으로 생각해서, 한 서버에 45개 (서비스당 15개  * 서비스 3개) 의 컨테이너를 올렸다고 할 경우.. 

 

nginX등을 통해 리버스 프록시 사용, 업스트림사용해 각각의 포트를 연결해서 하나인 것처럼 만들어야함

 

무중단배포 등을 지원하기 위해서, 커넥션 Req를 차단하거나 하는 기능 필요

 

롤백 프로세스도 고민해봐야함

... -> 자동화가 필요

 

 

8p. 오케스트레이션 - 여러대의 서버

앞의 케이스로, 서버가 여러 대 일 경우.

 

---

웹서비스_구성과_배포.ppt

 

2p. 인지도 없을 경우

Application : 워드프레스

Database : 마리아db || msSQL

 

 

3p. 인지도가 올랐음

WAS 분리, 리버스 프록시로 관리 시작

WebServer를 앞에 두구 WAS 분리, 뒷단에 DB

재기동도 한 대 씩 진행

 

 

4p. 유명해짐

로드밸런싱 업스트림통해 진행하기에 작업도 많고 ip도 항상 다름 -> 대응 어려움

 

로드밸런서 : 스위치 장비 (물리) L4, L7등 종류 많음.

L4는 OSI 7 레이어 중 TCP레이어,  네트워크 ip와 포트로 접속

L7 Application 레이어 HTTP 프로토콜 : Http 프로토콜 기능 사용 (헤더에 뭐 심고, 에이전트, ...)

 

서버를 그룹으로 묶음

로드밸런서를 통해 각각의 장비를 통해 서버에 진입

 

DB도  마스터/슬레이브로 확장하고

마스터를 조금 키움

 

RDBS - 스케일아웃 하기 힘든 구조. 스케일업 함 (수직 확장)

수평 확장을 하려면 레디스 같은 NoSQL서버.

 

 

5p. 글로벌 서비스 됨

금융권 등은 절대로 장애가 나면 안됨

품질향상필요

안정성 확보가 중요

 

로드밸런서 - 서버그룹 구간도 이중화. 

ex) 하이브리드 구성 (IDC를 public/private),

하이브리드 클라우드(AWS),

region(클라우드 리전단위로 분리가능. 서울/미국/... 처럼),

가용영역 분산처리 

 

MSA구조(요즘 트렌드)

앞단(public) - 프론트엔드 / openAPI 

사용자들이 직접 만나는 서비스

 

뒷단(private) - 백엔드/NoSQL(수평확장가능한 스토리지 구성) / 기타시스템(kafka,...)

public에서만 접근 가능하게끔

 

DB - RDBMS

 

 

6p. 배포전략 - 롤링 업데이트

점진적으로 하나하나 배포. 가장 많이 쓰는 방식

롤백이 필요한 경우, 배포도 마찬가지로 롤링

 

무중단배포

이전버전을 가지고 있다가 / 커넥션을 차단 / ??

 

 

7p. 배포전략 - 블루그린배포

블루(구) -> 그린(신)

심플하고 안정적! ()

티켓, KTO의 쉘 스크립트에서 이 방식을 응용해서 사용중 - 한 서버당 8개의 컨테이너  - 차이점은 마지막에 블루를 내려버림

롤백이 아주 빠름 (이전버전으로 바꾸기만 하면 돼서)

 

 

8p. 배포전략 - 카나리배포

5대 먼저 배포 -> 테스트 후 이상이 없다면 -> 나머지 15대 한번에 배포

 

 

---

쿠버네티스_스터디_발표자료.ppt

 

 

9p. 오케스트레이션 솔루션

쿠버네티스 - 많은 기능 지원, 인기 많음

여러 벤더사들이 쿠버네티스를 많이 사용하면서 사실상 쿠버네티스가 컨테이너 오케스트레이션의 표준이 되어가고 있음

 

 

blog.mirapps.net/kube-cluster/

쿠버네티스 클러스터 – Mir

10p. 클러스터 구조

크게는 마스터서버(Control Plane-Master) - 노드(Worker Node) 로 구성

 

Control Plane

모든 통신은 kube API-Server 가 맡음 (중계자. ex: 조원업 팀장님)

Controller Manager : 파드 관리 (ex. 박현준 차장님)

etcd : 파드의 상태값을 저장하는 DB

kube scheduler : 여러 자원들의 cpu사용률 등을 살펴보고 pod를 어디에 배치할 지 정하는 놈

Cloud Controller Manager : EKS AKS GKE

 

Controller Manager - etcd 간 직접 소통하는게 아니라

반드시 Kube API-Server를 통해서 소통

 

WorkerNode

kubelet : Kube API-Server가 어떻게 설정하라고 한 걸  반영해주는 애. 노드 대장

kube-proxy : 네트워크 관련 컴포넌트

Container : 컨테이너 런타임.  도커라고 보면 됨

 

---

blog.mirapps.net/kube-setup-linux/

쿠버네티스 설치 – Linux – Mir

 

 

11p. 마스터와 노드간 제어

kubectl 명령어 사용

API Request 직접 호출도 가능

 

 

blog.mirapps.net/kube-resource/

쿠버네티스 주요 자원 – Mir

파드~시크릿까지 실습 예정

레플리카셋, 디플로이번트로 관리해볼것임

 

 

---

blog.mirapps.net/kube-pod/

쿠버네티스 Pod – Mir

파드 : 도커컴포즈와 비슷함

 

파드 생성하기