1. 쿠버네티스란?

※ 쿠버네티스(Kubernetes) : container화된 application을 효율적으로 배포하고 운영하기 위해 설계된 오픈 소스 플랫폼

• 오늘날 application이 사용되면서 중요성이 높아지는 것이 지속적통합(CI)과 지속적배포(CD)

CI/CD(Continuous Integration/Continuous Delivery)

CI - 소프트웨어 개발을 할 때 테스트 단계에서만 테스트하는 것이 아니라, 일상적으로 빌드와 테스트를 수행하여 실제 동작을 확인하는 사이클을 돌면서 소프트웨어 품질을 관리한다. 일반적으로 CI를 위한 전용 소프트웨어나 SaaS를 이용하여 자동화

CD - CI의 범위를 확장해서 통합 테스트를 위한 스테이징 환경에 배포, 그리고 정식 서비스 배포까지 자동화 도구를 사용하여 수행하는 것을 말한다.

• 사용자에게 새로운 기능과 서비스를 빠르고 안정적으로 제공해야 하기 때문에 컨테이너 기술을 사용한다.
• application 실행에 필요한 라이브러리나 운영체제 패키지를 포함한 환경: 불변의 실행 환경(Immutable Infrastructure)
• 개발자 사이, 테스트와 운영 환경 사이의 차이를 없애, 개발 생산성을 높이고 안정적으로 배포 할 수 있는 환경 구축

 

1.1 쿠버네티스의 개요

※ 제공하는 기능

• 배포 계획에 맞춰 application을 신속하게 배포
  • 컨테이너 개수, CPU 사용률, 메모리 사용량을 설정 가능
  • 저장 공간, 네트워크 접근 제어, 로드밸런싱 기능 설정 가능
• 가동 중인 application의 scale up/down 가능
  • 요청이 많을 때 : 컨테이너 수를 늘려서 처리 능력을 높임
  • 요청이 적을 때 : 컨테이너 수를 줄여서 자원 점유율이나 요금을 줄임
• 새로운 버전의 application을 무정지로 업그레이드 가능
• 하드웨어 가동률을 높여 자원 낭비를 줄임

※ 쿠버네티스의 특징

• 다양한 환경에서 쿠버네티스 사용 가능
  • public cloud : 고객들 간에 공유하는 대신 저렴하고 신속한 운영이 가능한 인프라
  • private cloud : 독점적으로 사용하여 보안을 높일 수 있는 인프라 환경
  • multi cloud : 여러 퍼블릭 클라우드를 함께 사용하는 경우
  • hybrid cloud : 온프레미스와 public cloud를 함께 사용하는 경우
  • On-premise : 자사 설비를 이용해 application에 특화된 운영을 하는 경우
• 계속되는 변화를 전제로 설계된 높은 유연성과 확장성
  • 마이크로 서비스화된 application에 최적화된 실행 환경
  • 느슨한 결합에 의한 유연성, 교체 용이성
  • 다양한 스펙의 서버가 혼재하는 클러스터 구성에 사용 가능
  • 서버(노드)의 정지, 추가, 제거가 용이
  • 저장소나 로드밸러서의 동적 프로비저닝
  • public 클라우드 api와 연동한 쿠버네티스 조작
• 고가용성과 성능 관리
  • 서버 정지 시 application 재배포 자동화
  • application의 이상 종료 시 자동 재기동
  • 필요한 인스턴스의 개수를 유지
  • 높은 부하에서 자동 scale

 

1.2 탄생부터 현재까지의 역사

• 구글의 사내 운영 시스템인 Borg에서부터 출발
• 쿠버네티스는 CNCF의 대표적인 프로젝트로 운영됨

1.3 쿠버네티스의 발음과 로고에 대해

1.4 쿠버네티스가 해결하는 과제

과제1: application의 빈번한 출시

• 쿠버네티스의 롤아웃과 롤백 기능 : 새로운 기능을 빈번하게 출시하고 버그 수정을 긴급 투입하는 것과 같은 민감한 작업을 안전하게 자동화 해줌
• 정식 서비스 중인 application 컨테이너를 무정지로 교체하고, 교체 중에 발생하는 성능 저하와 프로그램 충돌로 인한 서비스 정지를 막기 위해 컨테이너 교체 정책(policy)를 설정 가능
• 롤아웃을 취소하고 롤백하는 것도 가능

과제2:무정지 서비스

• IoT가 발전되면서 IT기술이 사람들의 일상생활을 감싸기 시작하면서 서비스의 가용성이 중요한 요건이됨
• 쿠버네티스의 자기 회복 기능 : 무정지 서비스 운영을 도와줌
• 응답이 없어진 컨테이너를 재기동하고, 쿠버네티스 클러스터(K8s) 내에 지정한 수만큼 컨테이너가 돌도록 관리

과제3:초기 비용을 낮추고 비지니스 상황에 맞게 규모를 조정

• 컨테이너 기술은 application과 실행 환경을 하나로 묶어서 배포할 수 있게 해줌
• 복수의 노드위에서 컨테이너가 조화롭게 돌아갈 수 있도록 해주는 것이 쿠버네티스
• 비즈니스의 초기 단계에서는 스펙이 낮고 저렴한 가상 서버를 사용하다가, 비지니스가 확대되면 고성능의 가상 서버나 물리서버를 투입시키며 초기 비용을 낮춤
• K8s 클러스터 내에서 컨테이너를 다른 노드로 옮기기 위해서 해당 노드의 스케줄 정지, 노드의 모든 컨테이너를 추방 시키면 됨

과제4:쿠버네티스와 외부 서비스와의 연동

• database에 대한 컨테이너화는 신중하게 접근
• 클라우드의 DBaaS(Database as a Service)나 온프레미스에서 관리하는 데이터베이스를 연동 -> 외부 서비스를 내부 DNS에 등록하는 기능 제공

과제5:개발 환경과 운영 환경의 분리

• 컨테이너의 개발이 완료되어 테스트까지 끝났으면, 정식 서비스 배포 전까지는 이미지를 다시 빌드하지 않는다
• 운영환경에서 사용하는 endpoint나 인증 정보는 테스트 환경과 다르기때문에 database의 접속 주소나 HTTPS를 위한 인증서가 다름을 인식
• 클러스터를 여러 개의 가상 환경으로 분할하는 것이 가능
• 가상 환경에 설정파일, 보안이 필요한 인증서나 비밀번호를 저장 가능
• 위의 경우를 이용하면 테스트 환경에서 운영 환경으로 옮길때 이미지를 다시 만들 필요가 없고, 그대로 정식 환경에 배포 가능함

과제6:온프레미스와 클라우드 위에 구축

• 대형 클라우드 업체들은 EKS(AWS), AKS(Azure), IKS(IBM Cloud)와 같은 쿠버네티스 서비스를 제공
• 인프라의 복잡성을 감추며, 일관된 인터페이스로 다룰 수 있도록 설계
• 온프레미스와 클라우드 환경에서 동일한 인터페이스로 조작하여 운영

과제7:application 중심의 오케스트레이션

• public 클라우드로 application을 위한 인프라를 구축하는 노동과 시간이 줄어듦
• application 개발자가 YAML파일을 기술하여 쿠버네티스에 제출하면, 로드밸런서, 저장소, 네트워크, 런타임 등의 환경이 구성됨

과제8:특정 기업에 종속되지 않는 표준 기술

• 빅데이터 및 인공지능 기술이 기업 성장에 중요한 요소로 부각되고 있는 시점에 이 기술들의 실행 환경으로 주목받는 것이 컨테이어 기술과 쿠버네티스다
• 특정기업이 독점적인 기술에 의지하는 것은 리스크 관리 측면에서 지양점이지만, 쿠버네티스는 특정 회사에 종속되지 않은 표준 기술이다.

과제9:서버의 가동률 높이기

• CPU사용률이 낮은 서버가 많은 것은 클라우드 환경에서 바람직하지 않음
• 쿠버네티스에서 사용되는 컨테이너 기술을 application이 정해진 서버에서 돌지 않아도 된다는 자유를 제공
• CPU사용시간이나 메모리 요구량도 간단히 제어
• 서버의 CPU가동률을 높게 유지하면서도 안정적으로 서비스를 제공한다는 상반되는 요구 사항을 충족

 

1.5 쿠버네티스의 아키텍처

▲ 그림 3. 쿠버네티스의 아키텍처

• 클러스터 관리를 담당하는 마스터와 컨테이너화된 APPLICATION을 실제로 실행하는 노드라는 단 두 종류의 서버로 구성
• 마스터를 마스터 노드, 노드를 워커 노드로 기재할 수 있는 경우도 있는데, 노드는 초기에 미니언이라 불림
• 쿠버네티스 클러스터를 K8S클러스터라 표기, 쿠버네티스틑 K8S라고 줄여서 표기

SRE(Site Relability Engineer) 사이트 신뢰성 엔지니어

- 운영 업무, 운영의 신뢰성 향상, 자동화를 목적으로하는 프로그램 개발을 담당하는 엔지니어

• 마스터는 kubectl과 같은 API 클라이언트로부터 요청을 받아서 APPLICATION의 배포, 스케일 업/다운, 컨테이너의 버전 업 등의 요구를 처리
• 마스터는 K8S 클러스터의 단일 장애점(Single Point of Failure, SPOF)이 되지 않도록 다중화 할 수 있다.
• 쿠버네티스에 연결 가능한 노드의 개수는 버전 1.11 기준으로 5,000대.
  • 노드를 추가하고 제거하는 작업은 application이 돌아가는 중에도 실시
• K8s 클라스터의 외부에는 레지스트리가 있다. 도커의 레지스트리와 동일
• 각 노드에서 이미지를 다운로드할 수 있도록 네트워크상 접근 가능한 곳에 있어야 한다.