Docker_(5)

서버의 복잡도 상승 시 해결 방안

• 문서화
   - 서비스 상황, 셋업 방법 문서화
   - 문제 발생 시 해결 방법 문서화
   - 하지만, 서버를 일일히 관리하고 명령을 실행한 다는 것은 사실상 불가능
• 코드화
   - Infrastructure As Code : DevOps 엔지니어가 꼭! 알아야함
   - 자동화 된 코드 스크립트로 해결
   - 다수의 서버에 명령을 대신 실행
   - 다양한 툴이 존재
   - 단점 : Learning curve가 높음, 설치 시 소프트웨어 충돌 문제에는 도움이 안됨
• Virtual Machine 도입
   - 소프트웨어의 충돌 해결을 위해 사용 (하나의 Physical Server에 다수의 VM을 올리고 서비스 별로 하나씩 할당)
   - 단점 : VM의 리소스 소비가 크고 느림, 특정 VM 벤더 혹은 클라우드에 종속되어 버림 (Lock-in)
• Docker 도입
   - Docker Image를 통해 모든 소프트웨어를 어디서든 동작 가능 (리눅스에 최적화)
   - VM에 비해 리소스 낭비도 적고 실행시간도 빠름
   - 오픈소스이기에 Lock-in 이슈 없음
   - 단점이 거의 없지만, Container 증가 시 관리가 힘들어지는 점이 있음

---

Docker Container가 다수화가 될 때의 관리

• Container Orchestration이라고 부름
• 위의 문제를 효율적으로 관리하기 위한 도구
• 한 클러스터 안에 다양한 서비스들이 공존 (DB, Web Service, Backend...)
• 다양한 기능 제공 : 배포, 스케일링, 네트워크, 인사이트...
• 그 중 Kubernetes (K8s) 가 가장 많이 사용

---

Kubernetes (K8s)

• 컨테이너 기반 서비스 배포 / 스케일 / 관리 자동화를 해주는 오픈소스 프레임워크
• 가장 많이 사용되는 컨테이너 관리 (Orchestration) 시스템
• 확장성이 좋아 다양한 환경에서 사용
   - 머신러닝 : Kubeflow
   - CI / CD : Tekton
   - Service Mesh : Istio
   - Serverless : Kubeless
• 다수의 서버에 컨테이너 기반 프로그램을 실행하고 관리
• 기본 구조 : 마스터 - 노드
  • 노드 = 물리서버 or 가상서버
  • 클러스터 = 1 + 노드의 집합
  • 마스터는 클러스터 관리 역할 수행
  • Master에는 여러 프로세스 존재
     - API Server (Container로 동작) : kube-apiserver
     - Scheduler : Pods 생성과 할당
     - Controller Manager : 전체 상황 모니터링과 fault tolerance 보장
     - High Availability가 중요

---

Pod

• K8s 사용 시 컨테이너를 바로 다루지 않고 Pod를 거쳐 컨트롤
• K8s 사용자가 사용하는 가장 작은 빌딩 블록
• 1 Pod = 보통 하나의 container로 구성
• 네트워크 주소를 갖는 self-contained server