이 포스트는 2019년 6월 29일 토요일, SK플래닛 T아카데미에서 진행됐던 세미나에 가서 청강하고 작성했습니다.
현재 세미나 강의와 자료는 추후 이 곳에서 확인하실 수 있습니다.
노트 필기식으로 작성한 내용이기에, 존댓말을 사용하지 않은 점 참고하시기 바랍니다.

* 발표자 : 김충섭 (퍼플웍스) 님

What is Kubernetes?

쿠버네티스 인기

Docker는 배포에 대해 큰 특징점이 없다.
서버 2, 3대 정돈? 일일히 코드 입력 가능하지만, 이게 200대 300대 서버라면.. 일일히 서버 구성 코드를 입력하기 어렵다.
이를 위해, Nomad, Docker Swarm 등.. 이에 대한 컨테이너 관리 도구 춘추전국시대가 도래되었다.
오늘날은 Google이 만든 borg를 기반으로 만든 Kubernetes가 표준화!
이에 따라 패키지 매니저도 등장!

helm = Kubernetes Package Manager

Cloud Support

AWS EKS, GKE, Azure Container Service 등

Container Platform

Knative Serverless, Istio Service Mesh, kubeflow Machine Learning 등

결론

컨테이너 응용 프로그램의 배포, 확장 및 관리를 자동하는 오픈 소스 시스템
그리스어로 조타수, 조종사라는 뜻
K8s 라고 줄여서 부른다. (ubernete = 8)
Google이 만들었지만 CNCF 재단에 기부되어 오픈소스화

특징

기본 기능

상태관리 : 상태에 맞춰 자동으로 복구
스케줄링 : 조건에 맞는 노드에 컨테이너 배치
클러스터링 : 가상 네트워크를 통해 하나의 서버에 있는 것처럼 통신
서비스 디스커버리 : 서로 다른 서비스 쉽게 통신
리소스 모니터링
스케일링
Roll-Out, Rollback

빠른 업데이트

1.10 이후(2018/3/27) 많은 부분이 안정화됨
굉장히 빠르고 업데이트, 윈도우용 업데이트 위주로 작동됨 (현재 19.6.29 기준)

다양한 배포 방식

Replica Set
Stateful Sets : 클러스터링을 세밀하게 조절하고 싶을 때 사용, 순차적으로 진행하기에 안정적.
Job : CronJob 과의 연계
Replication Controller : (현재 Deprecated)

Ingress 설정

nginx 설정과 유사

Namespace & Labeling

Namespace : 동일한 물리적 클러스터 기반의 복수의 가상 클러스터
Labeling : 각기 다른 컨테이너를 Label로 구별하는 것

RBAC (role-based access control)

누가 어떤 기능을 가지고 있는지 쉽게 제어가 가능하다

누가 : Subjects
어떻게 : Pod 권한을 조정
무엇을 : Operations(행동) 조정

기본개념

Desired State

개발자나 관리자가 궁극적으로 원하는 서버의 상태
현재 상태(Current State)를 서버 관리자가 원하는 상태(Desired State)로 변경해야한다.
서버 관리자가 원하는 서버의 갯수를 지정하면, Kubernetes가 이에 판단하여 자동으로 작동함.

Kubernetes Object (The Illustrated Children’s Guide to Kubernetes 참고)

Nametags : Label과 같은 의미

Pods : 컨테이너들의 집합

ReplicaSet : 여러 동일한 Pods을 여러 개로 확장

k8s service

Volumes

Namespace

YAML 파일로 정의

...

spec:
	containers:
	- name: busybox
	image: busybox:1.25

...

결론

원하는 상태(Desired State)를 다양한 오브젝트(Object) 에 라벨(Label)을 붙여 정의(YAML)하고, API 서버에 전달한다.

아키텍쳐

전체적인 흐름

kubectl - master - Many Nodes
(In master) Api Server - One Node
(In Node) kubelet - pod - master

kubectl

명령어로 작동

Master - Node

Master

다양한 모듈이 확장성 고려
보통 3대를 구성하여 안정성 높임
Scheudler, Kube-Controller, Cloud-Controller가 각각 존재
API Server
Controller Manager : 다양한 컨트롤러를 관리하고 API Server와 통신하여 작업 수행
Scheduler : 서비스를 리소스 상황에 맞게 적절 노드에 배치
etcd : 가볍고 빠른 분산형 key-value 저장소 / 설정 및 상태를 저장

Node

마스터 서버와 통신하면서 필요한 Pod을 생성하고 네트워크와 볼륨을 설정
kubelet
Proxy
Docker(containerd 또는 rkt 또는 Hyper)

결론

단점

복잡한 개념 : 확장성까지 고려하게 된다면 굉장히 많은 개념 습득을 필요하다.
복잡한 설치 : 설치 방식만해도 20가지가 넘을 정도로 복잡한데, 이를 통일하여 설치하는 방법을 따로 익혀야한다.
무거운 환경 : 리소스 사용이 많다.
복잡한 설정 파일 : Docker Swarm과는 달리 Config 코드가 2배, 3배 넘게 길다

질문

IP 주소를 일일히 입력하여 서비스과 서비스 사이 통신을 진행해야하나요?

IP 주소를 직접 입력하지 않고, 서비스의 이름으로 직접 접근하는 것이 일반화.

실습시 minikube 쓰지 않는 이유는?

실습할때 서로 다른 환경때문에 생기는 이슈가 많다.
보안 네트워크 프로그램이라도 설치되어 있을시 해결 자체가 매우 어렵다.

참고

김충섭님 블로그 (subicura blog)