[대세는쿠버네티스] 1. 기초다지기

@BeforeAll

• 인프런에 존재하는 [대세는 쿠버네티스]라는 강의를 보고 내용을 정리
• 인프런에 쿠버네티스 스터디가 생겨서 시작했는데 멋진 분들이 많아서
  자극도 되고 덕분에 오랜만에 잊혀진 블로그도 들어오게되네;;

Why Kubernetes?

• 강의의 해당 챕터는 간단한 예시를 보여줌
• 쿠버네티스를 사용하지 않을때와 사용할때의 의 트래픽이나 장애 대응에 대해 그림으로 보여줌.
• 하지만 제목에 말한 질문에는 저는 달리 대답하고 싶긴하다

• 강의 말대로 대세는 쿠버네티스이기 때문입니다.(엄청난 인기)

• 저는 개발 공부를 좋아하고 얼리아답터였지만
  나이를 먹으면서 레이트아답터로 바뀌었습니다

• 내 아이들과 보내는 시간이 가장 소중하기 때문에
  정말 필요로 할때 효율적으로 익히는 것으로 바뀌었는데요

• 그래서 대세가 되는 기술을 익히는데 주력하게 됩니다

• 이런 제가 쿠버네티스를 공부하게 되는 것은 정말로 대세란 뜻입니다 ㅎ

쿠버네티스 소개

• 1주일에 20억개 컨테이너를 생성하는 구글이 컨테이너 배포시스템으로
  사용하던 borg를 기반으로 만든 오픈소스
• 2015년 : v1.0 release
• 현재는 CNCF 로 이관됨 - 완전히 오픈 소스가 되었다고 해도 무방

• 쿠버네티스 공식 홈페이지에서 말하기로는
  • 행성 스케일 : 구글보다 적게 사용하면 OK
  • 무안한 유연성 : 다양한 요구사항을 만족시킬 수 있는 유연함
  • 어디서나 동작 : 오픈소스로써 클라우드/온프레미스 전부 가능

왜 쿠버네티스?

• 오픈소스

• 공식 홈페이지에서만 150개 넘는 모임을 소개, 활발한 활동

• 참가 기업 : 구글 , 화훼이, VMware, 마이크로소프트, IBM등

• 엄청난 인기

  • 깃허브 스타 수가 7만9천개에 육박
  • CNCF 프로젝트중 가장 많이 production에 도입되는 프로젝트
  • 카카오, 라인등의 기술 블로그에서도
    몇 년 전부터 대용량 쿠버네티스 클러스터로
    구성되는 아티클이 보여지곤 했음

• 무한한 확장성

  • 머신러닝
    • 
  • CI/CD
    • 
  • 서비스 메시
    • 
  • 서버리스
    • 

  • 쿠버네티스가 또하나의 플랫폼이 되는 상황

• de facto

  • 데 팍토 - 법률등의 명시적인 방법으로 인정되진 않지만 다들 암묵처럼 공식으로 여기는 것을 뜻함.
  • 컨테이너 오케스트레이션의 데 팍토
  • 현재 클라우드 네이티브의 핵심 역할
  • 기존 오케스트레이션 툴(Rancher등)도
    기존 자체적으로 구성했던 툴을 쿠버네티스 기반으로 돌아가도록 바뀜.
  • 도커도 도커 스웜을 밀다가 어쩔 수 없이 이제 쿠버네티스를 지원
    (개인적으로는 도커 스웜이 잘되길 정말 빌었는데..)
  • 모든 퍼블릭 클라우드의 매니징 서비스 - AWS의 EKS, Azure의 AKS, Google의 GKE..

VM vs Container

• 기존 VM들의 전성기가…그리고 잘나갈때가 있었음(도커 이전 시점)

• OS의 에뮬레이터형태의 VM에서 하이퍼바이저 형태의 VM이 등장하면서 KVM, Vmware ESXi가 유행하던 시절

• 여기 저기서 컴퓨터들 모아서 클러스터링 하고 Vmware ESXi 까는게 범유행하던 시절로 떠오릅니다
  (Nas도 시놀로지 안쓰고 굳이 HP MicroServer에 Vmware ESXi 깔아서 서비스 하는게 당연시 되던)

• VM(하이버바이저 형태) 장점 (도커 이전 시점)

  • 서버 가상화
    • 많은 물리서버에 수많은 가상 서버 사용 - 노는 자원 없이 활용율 개선
    • 하이퍼 바이저 위에서 적절한 리소스의 가상머신의 프로비저닝이 가능
    • 추가 하드웨어 없이 장애 대응, 이중화 대응
  • 시스템의 여러 부분과 격리 되며 효율적으로(예전 에뮬레이터의 VM)보다 자원 관리 가능
  • 성능도 많이 향상됨 - (역시 예전 에뮬레이터형태의 VM보다)
  • 도커 이전의 클라우드 컴퓨팅을 설명할때 VM을 늘 언급

• 도커 등장과 컨테이너

  • 기존에도 컨테이너 기술이 존재는 함
    • cgroup, chroot등의 격리환경+레이어 형태의 파일 저장시스템 결합
    • 손이 많이 감
  • 도커 등장
    • 위의 과정을 모아서 엄청나게 쉽게 컨테이너 제어와 사용이 가능해짐
    • 도커 허브 등장 - 내가 필요한 컨테이너 이미지가 이미 존재()

• 컨테이너

  • 운영체제의 커널 한개에서 하나의 목적을 위해 격리된 독립적으로 작동하는 프로세스
    • 각각 독립적인 OS 커널이 필요한 가상 머신과는 달리 하나의 커널을 여러개가 사용 가능
    • 거치는 단계가 적어서 속도도 빠르고 자원도 효율적으로 사용
  • 각 컨테이너는 다른 컨테이너의 영향없이 독자적인 격리 영역 사용 가능

• 컨테이너의 장점

  • 게스트 OS가 필요없음 - VM의 기가 단위에서 메가바이트로 크기가 줄어듬
  • 뛰어난 성능 - 벤치마크 결과 호스트 네이티브의 99% 성능
  • 작은 단위의 영역 분리 및 격리 가능

• 현재의 개발은 컨테이너가 주도

  • 컨테이너 기술이 없었다면 사실상 지금 유행하는 클라우드 네이티브, DevOps도 없음
  • 컨테이너 오케스트레이션인 쿠버네티스도 존재하지 않음
  • 컨테이너의 유일한 한계 : 컨테이너가 기존 OS와 호환되어야 한다

• 컨테이너 오케스트레이션의 필요

  • 컨테이너가 대세가 되고 MSA가 대세가 되며 어플리케이션이 수많은 컨테이너가 필요해짐
  • 수많은 컨테이너에 대한 운영이나 제어의 어려움
  • 컨테이너 오케스트레이션 시스템 의 등장 : 이런 부분을 자동화
  • 서버들을 클러스터로 구성하면 서버가 1대든 100대든 한번의 명령으로 자동 배포 가능
  • 장애가 발생시에 컨테이너 오케스트레이션이 알아서 장애 대응
  • 다수의 서버 위에서 컨테이너의 전반적인 라이프 사이클을 관리

Getting started - Kubernetes

• ‘Hello Kubernetes!’ 를 출력하는 프로그램을 pure 서버, 그리고 도커, 컨테이너 안에서 돌려본다

• hello world - nodejs 프로그램

  var http = require('http');
  var content = function(req, resp) {
   resp.end("Hello Kubernetes!" + "\n");
   resp.writeHead(200);
  }
  var w = http.createServer(content);
  w.listen(8000);

• 서버에서 실행

  node hello.js

• 도커에서 실행

  • 도커파일 생성

    FROM node:slim
    EXPOSE 8000
    COPY hello.js .
    CMD node hello.js

  • 이미지 빌드

    docker build -t kubetm/hello .
    -t : 레파지토리/이미지명:버전
    
    docker images
    docker run -d -p 8100:8000 kubetm/hello
    -d : 백그라운드 모드
    -p : 포트변경
    
    docker ps
    docker exec -it c403442e8a59 /bin/bash

  • 이미지 push

    docker login
    docker push kubetm/hello

• 쿠버네티스에서 실행

  • pod 반영

    apiVersion: v1
    kind: Pod
    metadata:
      name: hello-pod
      labels:
        app: hello
    spec:
      containers:
      - name: hello-container
        image: kubetm/hello
        ports:
        - containerPort: 8000

  apiVersion: v1
  kind: Service
  metadata:
    name: hello-svc
  spec:
    selector:
      app: hello
    ports:
      - port: 8200
        targetPort: 8000
    externalIPs:
    - 192.168.0.30

Kubenetes Overview

• 앞으로 배울 전체적인 청사진을 보여줌

  

• 청사진의 오브젝트
  (아직 배우는 단계이므로 밑의 표는 틀릴 수도 있음!)

노드	용도
노드	컨테이너가 배치되는 서버
네임스페이스	쿠버네티스 클러스터 안의 가상 클러스터
파드	컨테이너 집합 중 가장 작은 단위, 컨테이너 실행 방법을 정의
레플리카셋	같은 스펙을 갖는 파드를 여러 개 생성하고 관리하는 역할
디플로이먼트	레플리카셋의 리비전 관리
서비스	파드 집합에 접근하기 위한 경로 정의
인그레스	서비스를 쿠버네티스 클러스터 외부로 노출
컨피그맵	설정 정보를 정의하고 파드에 전달
퍼시스턴트볼륨	파드가 사용할 스토리지의 크기 및 종류 정의
퍼시스턴트볼륨클레임	퍼시스턴트볼륨 동적 확보
스토리지클래스	퍼시스턴스 볼륨이 확보하는 스토리지 종류 정의
스테이트풀세트	같은 스펙으로 모두 동일하지만 상태값을 갖는 파드를 여러 개 생성하고 관리
잡	상주 실행을 목적으로 하지 않는 팟을 여러개 생성 후 정상 종료 보장
크론잡	cron 문법으로 스케쥴링 되는 잡

Related POST

• [대세는쿠버네티스] 1. 기초다지기
• [대세는쿠버네티스] 2. 기본 오브젝트
• [대세는쿠버네티스] 3. [기초편] 컨트롤러
• [대세는쿠버네티스] 3. [중급] Pod -1