Kubernetes

이전 작성 글: Kubernetes

The Illustrated Children's Guid to Kubernetes
[토크ON세미나] 쿠버네티스 살펴보기 1강 - 컨테이너 오케스트레이션
[토크ON세미나] 쿠버네티스 살펴보기 2강 - 쿠버네티스 & 쿠버네티스 아키텍쳐

GitHub: subicura/workshop-k8s-basic

컨테이너

도커가 등장하기 전 서버 운영

• 서버의 상태를 관리하기 위한 노력

자체 서버 운영

• 서버를 설정하기 위해 많은 노력과 시간이 필요
• 성능이 좋은 걸 미리 구매하고 효율적인 사용을 위해 여러 애플리케이션을 설치

• 어려운 상태 관리
  • 특정 시점의 서버 상태를 누가 ∙ 언제 ∙ 어떻게 작업했는지 알 수 있을까?
  • PPT를 만들고 설치 화면을 캡쳐한 메뉴얼이 있는데 믿을 수 있을까?
  • 똑같은 서버를 하나 더 만들 수 있을까?

• 설정 관리 도구 ( Configuratin Management )
  • 명령어를 통한 서버 관리를 지양
  • 상태를 관리하는 코드 ( 또는 설정 ) 를 이용하여 서버 관리
  • 선언적 서버 상태 정의
  • 서버의 상태가 재현 가능해짐 ( 불완전 )
  • 서버 운영의 협업이 가능해짐 ( 소스관리 ∙ 코드리뷰 )

가상 머신

• 가상 머신의 등장
  • 하나의 서버에 여러 개의 가상 서버를 설치할 수 있음
  • 다양한 버전의 Java 와 여러 개의 데이터베이스를 쉽게 사용
  • 서버의 상태를 이미지로 저장할 수 있음
  • 새로운 서버를 만들고 기존 서버의 내용을 복사할 수 있음

• Immutable ( 변하지 않는 )
  • Mutable vs Immutable
    • 서버에 설치된 애플리케이션을 새로운 버전으로 업데이트 하면 mutable
    • 새로운 버전이 설치된 서버의 상태를 이미지로 만들고 교체하면 immutable
  • 개념이 단순해짐
    • 기존 상태를 고려할 필요 없이 통째로 서버를 교체
  • 생각보다 어렵고 느리고 특정 회사의 제품을 써야함

클라우드

• AWS ∙ Google Cloud ∙ Azure ∙∙∙
• 하드웨어 파편화 문제 해결
• 가상화된 환경만으로 아키텍쳐 구성이 가능해짐
• 이미지를 기반으로한 다수의 서버 상태 관리
  • 상태 관리에 대한 새로운 접근
  • 서버 운영의 문제는 여전히 그대로 남아있음
• 마치 전기를 사용하듯 편리

• 클라우드 이미지 단점
  • 어떻게 만들었는지 모름
  • 처음부터 다시 만들 수 없음
  • 관리 어려움

PaaS ( Platform as a Service )

• Heroku ∙ Netlify ∙ AWS Elastic Beanstalk ∙ Google Cloud App Engine ∙∙∙
• 서버를 운영하는 것은 복잡하고 어려움
• 소스 코드만으로 배포가 가능함
• 일반화된 프로비저닝 방법을 제공
  • 프로비저닝 과정에 개입할 수 없음
  • 예시: Heroku 의 buildpacks
• PaaS 는 서버 운영의 은총알

• PaaS 단점
  • 애플리케이션을 PaaS 방식에 맞게 작성해야함
  • 서버에 대한 원격 접속 시스템을 제공하지 않음
  • 서버에 파일 시스템을 사용할 수 없음
  • Site 패키지를 설치할 수 없음
  • 로그 수집을 제한적인 방식으로 허용 ( STDOUT )
  • 애플리케이션 배포에 대한 새로운 패러다임

• PaaS 에서 할 수 있을까?
  • 크론잡 ( 문자 발송 ∙ 예약 ∙ 정산 등 )
  • 데이터 분석 ( BigQuery ∙ S3 등 연동 )
  • 로그 분석 ( 엘라스틱 서치 ∙ 스택드라이버 ∙ 클라우드와치 등 )
  • 애플리케이션 성능 모니터링
  • A/B 테스트 ∙ Canary 배포
  • 네트워크 ∙ 스토리지 설정

도커

• 도커란?
  • 2013년 DotCloud ( 현 Docker ) 에서 첫 공개
  • 컨테이너: 격리된 환경에서 작동하는 프로세스
  • 리눅스 커널의 여러 기술을 활용
  • 하드웨어 가상화 기술보다 가벼움
  • 이미지 단위로 프로세스 실행 환경을 구성

• 도커의 특징: 확장성
  • 도커가 설치되어 있다면 어디서든 컨테이너를 실행할 수 있음
  • 특정 회사나 서비스에 종속적이지 않음
  • 쉽게 개발 서버를 만들 수 있고 테스트 서버 생성도 간편함

• 도커의 특징: 표준성
  • 도커를 사용하지 않는 경우 ruby, nodejs, go, php 로 만든 서비스들의 배포 방식은 제각각 다름
  • 컨테이너라는 표준으로 서버를 배포하므로 모든 서비스들의 배포 과정이 동일해짐

• 도커의 특징: 이미지
  • 이미지에서 컨테이너를 생성하기 때문에 반드시 이미지를 만드는 과정이 필요
  • Dockerfile 을 이용하여 이미지를 만들고 처음부터 재현 가능
  • 빌드 서버에서 이미지를 만들면 해당 이미지를 이미지 저장소에 저장하고 운영 서버에서 이미지를 불러옴

• 도커의 특징: 설정
  • 설정은 보통 환경변수로 제어함
  • MYSQL_PASS=password 와 같이 컨테이너를 띄울 때 환경변수를 같이 지정
  • 하나의 이미지가 환경변수에 따라 동적으로 설정 파일을 생성하도록 만들어져여함

• 도커의 특징: 자원
  • 컨테이너는 삭제 후 새로 만들면 모든 데이터가 초기화됨
  • 업로드 파일을 외부 스토리지와 링크하여 사용하거나 S3 같은 별도의 저장소가 필요
  • 세션이나 캐시를 파일로 사용하고 있다면 memcached 나 redis 와 같은 외부로 분리

• 도커가 가져온 변화
  • PaaS 와 같은 제한 없음
  • 클라우드 이미지보다 관리하기 쉬움
  • 다른 프로세스와 격리되어 가상머신처럼 사용하지만 성능저하 거의 없음
  • 복잡한 기술 ( namespace ∙ cgroups ∙ network 등 ) 을 몰라도 사용할 수 있음
  • 이미지 빌드 기록이 남음
  • 코드와 설정으로 관리 > 재현 및 수정 가능
  • 오픈소스 > 특정 회사 기술에 종속적이지 않음

• Blue - Green 배포
  • 애플리케이션을 업데이트 하기 위해 컨테이너를 교체하는 방식 사용

• 서비스 디스커버리 ( Service Discovery )
  • 서버들의 정보 ( IP ∙ Port 등 ) 를 포함한 다양한 정보를 저장하고 가져오고 값의 변화가 일어날 때 이벤트를 받아 자동으로 서비스의 설정 정보를 수정하고 재시작하는 개념
    • 새로운 서버가 추가되면 서버 정보를 key/value store 에 추가함
    • key/value store 는 directory 형태로 값을 저장함
      • /services/web 하위를 읽으면 전체 web 서버 정보를 읽을 수 있음
    • key/value store 를 watch 하고 있던 configuration manager 가 값이 추가되었다는 이벤트를 받음
    • 이벤트를 받으면 템플릿 파일을 기반으로 새로운 설정 파일을 생성
    • 새로운 설정 파일을 만들어 기존 파일을 대체하고 서비스를 재시작함

• docker-gen
  • docker 의 기본 기능을 적극 활용한 service discovery 도구
    • 도커 데몬이 가지고 있는 컨테이너 정보를 그대로 이용
    • 컨테이너를 실행할 때 입력한 환경변수를 읽음
    • VIRTUAL_HOST=www.subicura.com 과 같이 환경변수를 지정하면 이를 보고 nginx 의 virtual host 설정 파일들을 구성함

컨테이너 오케스트레이션

• 여러 대의 서버와 여러 개의 서비스를 편리하게 관리해주는 작업

스케줄링

• 컨테이너를 적당한 서버에 배포해주는 작업
• 여러 대의 서버 중 가장 할 일 없는 서버에 배포하거나 그냥 차례대로 배포 또는 아예 랜덤하게 배포
• 컨테이너 개수를 여러 개로 늘리면 적당히 나눠서 배포하고 서버가 죽으면 실행 중이던 컨테이너를 다른 서버에 띄워줌

클러스터링

• 여러 개의 서버를 하나의 서버처럼 사용
• 작게는 몇 개 안되는 서버부터 많게는 수천 대의 서버를 하나의 클러스터로
• 여기 저기 흩어져 있는 컨테이너도 가상 네트워크를 이용하여 마치 같은 서버에 있는 것처럼 쉽게 통신

서비스 디스커버리

• 서비스를 찾아주는 기능
• 클러스터 환경에서 컨테이너는 어느 서버에 생성될지 알 수 없고 다른 서버로 이동할 수도 있음
• 따라서 컨테이너와 통신을 하기 위해서 어느 서버에서 실행 중인지 알아야 하고 컨테이너가 생성되고 중지될 때 어딘가에 IP 와 Port 같은 정보를 업데이트 해줘야 함
• key/value 스토리지에 정보를 저장할 수도 있고 내부 DNS 서버를 이용

로깅 ∙ 모니터링

• 여러 대의 서버를 관리하는 경우 로그와 서버 상태를 한 곳에서 관리
• ELK 와 prometheus 등 다양한 도구 사용

docker swarm

• docker 에서 만들 컨테이너 오케스트레이션 도구
• 호스트 OS 에 Agent 만 설치하면 간단하게 작동하고 빠름
• 단순한 구조에서 효과적

kubernetes

• 구글에서 개발한 컨테이너 배포 ∙ 확장 ∙ 운영 도구
• 사실상 컨테이너 오케스트레이션 표준
• 대규모에 적합
• 다양한 생태계 구축되어 있음

서비스 매시 ( Service Mash )

• 넷플릭스 OSS 에서 지원하는 기능과 분산 모니터링 같은 기능을 프록시 방식으로 제공
• 특정 언어에 종속적이지 않고 어떤 언어나 어떤 프레임워크에서도 사용 가능

서비스 매시 기능

• Service Discovery ( 서비스 발견 )
• Load Balancing ( 부하 분산 )
• Routing Management ( 경로 관리 )
• Traffic Management ( 트래픽 관리 )
• Resilient ( 운영 탄력성 )
• Fault Injection ( 오류 주입 )
• Logging / Monitoring ( 로깅 / 모니터링 )
• Distributed Tracing ( 분산 추적 )
• Security ( 보안 )
• Authentication / Authorization ( 인증 / 인가 )

결론

• 서버 상태를 관리하기 위한 노력
  • 서버 생성을 쉽고 편리하게
  • 명령어가 아닌 코드와 설정을 사용
  • 격리된 환경을 이용하여 독립적인 실행환경 구성
  • Immutable 하게 애플리케이션을 관리하고 스토리지 또는 로그를 분리하여 관리
  • 이미지를 쉽게 마들고 편리하게 사용
  • 로드 밸런서와 프록시 서버 등 자주 사용하는 기술을 쉽게 사용
  • 확장 가능한 설계

왜 서비스 매시인가?

• retry 를 구현해보자
  • 서비스를 요청한다
  • 요청이 실패하면 동일한 요청을 N번 더 시도한다

쿠버네티스

• 2013년 3월 도커가 등장
  • 컨테이너 기반의 도커는 서버 관리 방식을 완전히 바꾸고 있음

• 쿠버네티스
  • google 이 만듬
  • 1주일에 20억개의 컨테이너를 생성하는 google 이 컨테이너 배포 시스템으로 사용하던 borg 를 기반으로 만든 오픈소스
  • 쿠버네티스는 컨테이너 응용 프로그램의 배포∙확장 및 관리를 자동화하는 오픈 소스 시스템

• 클라우드 서포트
  • AWS: EKS ( Amazon Elastic Container Service for Kubernetes )
  • Google Cloud: GKE ( Google Kubernetes Engine )
  • Azure: Container Service

쿠버네티스 특징

기본 기능

• 쿠버네티스는 프로덕션 수준의 컨테이너 오케스트레이션으로 기본 기능을 충실하게 제공

• 상태 관리
  • 상태를 선언하고 선언한 상태를 유지
  • 노드가 죽거나 컨테이너 응답이 없을 경우 자동으로 복구
• 스케줄링
  • 클러스터의 여러 노드 중 조건에 맞는 노드를 찾아 컨테이너를 배치
• 클러스터
  • 가상 네트워크를 통해 하나의 서버에 있는 것처럼 통신
• 서비스 디스커버리
  • 서로 다른 서비스를 쉽게 찾고 통신할 수 있음
• 리소스 모니터링
  • cAdvisor 를 통한 리소스 모니터링
• 스케일링
  • 리소스에 따라 자동으로 서비스를 조정함
• RollOut ∙ RollBack
  • 배포 ∙ 롤백 및 버전 관리

다양한 배포 방식

• 배포 방식
  • = 컨테이너를 클러스터에 올리는 방식

Ingress 설정

• = nginx 기능

Namespace & Label

RBAC

• 역할 관리
  • docker swarm 과 차별화되는 기능
  • 누가 / 무엇을 / 어떻게

다양한 지원

• 다양한 환경을 지원

쿠버네티스 기본 개념

The Illustrated Children's Guid to Kubernetes

Desired State

• 가장 중요한 개념

Kubernetes Object - Pod

• 쿠버네티스는 Pod 으로 관리
  • Container 를 한번 더 감싸서 Pod 을 만듬
  • 보통 Container 하나에 Pod 하나를 만들지만 Pod 하나에 Container 여러개가 포함될 수도 있음

Kubernetes Object - ReplicaSet

Kubernetes Object - etc

• Service
• Volume
• Namespace
• ∙∙∙

Object Spec - YAML

• 상태 관리 파일
  • 서버 관리자가 원하는 Desired State 의 상태
  • YAML 파일로 정의하고 쿠버네티스에 알려주면 Desired State 로 가기 위해 Current State 를 변화시킴

apiVersion: v1
kind: Pod
metadata:
    name: example
spec:
    containers:
    - name: busybox
        image: busybox:1.25

Kubernetes

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

쿠버네티스 구조

Server - Agent

Master - Node

• Master
  • 마스터 서버는 다양한 모듈이 확장성을 고려하여 기능별로 쪼개져 있는 것이 특징
  • 관리자만 접속할 수 있도록 보안 설정을 해야 하고 마스터 서버가 죽으면 클러스터를 관리할 수 없기 때문에 보통 3대를 구성하여 안정성을 높임

• Node
  • 노드 서버는 마스터 서버와 통신하면서 필요한 Pod 을 생성하고 네트워크와 볼륨을 설정

• kubectl
  • 명령 도구

Master