[NHN Cloud] NKS로 Cloud Native 시작하기 - 1

hwwwa·2023년 8월 25일
NHNCloudk8s
0
post-custom-banner

NHN Cloud 교육센터 NKS로 Cloud Native 시작하기 오프라인 교육 강의 요약

1편 - 이론 정리 (현재 글)
2편 - NKS, NCR 실습 진행

1. Cloud Native

Cloud Native 도입 배경

  • 클라우드 플랫폼 비즈니스가 확대됨에 따라 애플리케이션간의 협업과 통합의 중요성 필요
  • 비즈니스 변화에 신속한 대응 체계 필요
  • 새로운 요구사항에 대해 빠르게 대응하면서 유연하고 신속한 확장성 요구
  • 장애를 사전에 예방하고 발생시 신속히 대응할 수 있는 능력 중요

Cloud Native 정의

  • Cloud Native 란?
    • 클라우드의 규모와 크기 조정 및 성능에 최적화되어 있는 애플리케이션을 개발하기 위한 접근 방식과 기술
    • 논리적 솔루션을 포함하여 물리적인 인프라 자원 요소들을 해결할 수 있는 일련의 서비스
  • Cloud Native 프로젝트
    • kubernetes, harbor, helm, prometheus, argo, flux, etcd, ...

Cloud Native의 장점

보다 빠르고, 편하고, 유연하다.

Cloud Native 4대 요소

Cloud Native 발전 형태

NHN Cloud의 Cloud Native

구성

NHN Kubernetes Service (NKS)

  • NHN Cloud 서비스를 통해 Cloud Native 핵심기술인 컨테이너 오케스트레이션할 수 있도록 지원하는 서비스
  • 주요기능
    • NHN Cloud에 최적화된 Kubernetes 클러스터 생성 관리
    • Kubernetes 클러스터 웹 콘솔 제어 기능 제공
    • kubectl config 설정 파일 (yaml) 파일 제공 및 연동
    • NHN Cloud Web Console을 통해 편리한 가용성 관리 지원
    • 빠른 Kubernetes 최신 버전 제공
  • 서비스 대상
    • 애플리케이션을 컨테이너화하여 서비스하는 사용자
    • 컨테이너화 된 애플리케이션을 서비스할 때 컨테이너 오케스트레이션이 필요한 사용자
  • 쿠버네티스 인증 획득, 공인 쿠버네티스 제공사 자격 획득, PaaS- TA 확장성 확인서 취득

NHN Container Registry (NCR)

  • Docker 컨테이너 이미지를 쉽고 안전하게 저장, 관리하고 배포할 수 있는 컨테이너 레지스트리 서비스
  • NKS와 연동하여 사용자의 애플리케이션을 손쉽게 컨테이너 환경으로 구축 가능
  • 주요 기능
    • Docker 이미지 매니페스트 v2 호환으로 Docker 명령줄 도구 지원
    • HTTPS 암호화, NHN Cloud 인증 및 권한 관리를 통한 보안성 강화
    • NHN Clou d Object Storage 기반의 확장성 및 안정성 제공
    • 웹 콘솔을 통한 레지스트리 관리 가능
  • 구성 요소
    • 레지스트리: 컨테이너 이미지 보관, 관리 단위
    • 이미지: 아티팩트(버전 관리)의 집합
    • 아티팩트: 하나 이상의 레이어를 가지는 특정 컨테이너 이미지 빌드를 의미
    • 태그: 아티팩트를 구분하기 위한 일종의 식별자

NHN Container Service (NCS)

  • 컨테이너 구동 환경을 제공하는 서비스
  • VM 인스턴스, Kubernetes와 같은 컨테이너 실행 환경을 구성하지 않아도 NCS 서비스를 이용해 컨테이너 실행 가능

2. 컨테이너 기술

컨테이너 기술의 개요와 필요성

  • 컨테이너 기술의 등장 배경
    • 프로그램들이 서로 영향을 주지 않고 사용할 수 없을까?
    • 다양한 OS 환경을 구현할 수 없을까?
    • 애플리케이션마다 자원을 독립적으로 관리할 수 없을까?
    • 복구 또는 백업 대비를 쉽게할 수 없을까?
    • 구성 시 비용과 시간을 줄일 수 없을까?
    • 특정 App만 구동하는 데 불필요한 기능을 제거할 수는 없을까?
    • 안정화 상태에서 그대로 보존하며 운영할 수 없을까?
    • 편리하게 백업/복원을 할 수 없을까?

Immutable Infrastructure 추상화 패러다임

  • OS와 서비스 환경 (런타임,코드등) 을 분리하고 한 번 설정한 이미지 (환경요소 등) 는 변경하지 않는다는 개념
  • Infrastructure 의 추상화로 사용자는 별도로 Infra 환경에 신경쓰지 않고 애플리케이션에 집중 가능
  • 서비스 환경을 이미지로 생성하고, 이를 컨테이너 단위로 배포/운영하는 방식
  • 장점
    • 관리 편의성: 이미지만 관리하면 되고 버전 관리를 활용 가능
    • 테스트: 개발 환경과 운영 환경이 동일하게 구성
    • 휴대성: 0S와 서비스 환경을 분리하여 가벼움
    • 충돌의 영향을 최소화 가능
    • 독립적으로 다양한 서비스를 제공 가능

컨테이너

  • 호스트 0S상에 논리적인 구획 (컨테이너) 을 만들고, 애플리케이션을 작동시키기 위해 필요한 라이브러리, 애플리케이션 등을 하나로 모아 하나의 Image로 만든 후 가상화하여 운용하는 것

  • 초기에는 가상화 환경으로 리소스를 할당받아 동작되는 형태(VM Ware, Virtual Box)를 사용하였으나, OS 위에 또 OS를 띄우지 않고 앱만 여러개 띄우기 위해 컨테이너가 등장하게 됨

컨테이너 동작 원리

LXC 동작 환경

chroot를 통해 최상위루트처럼 속여서 컨테이너가 루트처럼 동작할 수 있도록 하는 Namespace를 사용

도커는 사용자가 편하게 컨테이너 관련 기술을 구동할 수 있게 함. 컨테이너를 관리하는 것은 쿠버네티스

컨테이너 동작 절차 (Docker)

컨테이너 기술의 장점

  • 가벼운 가상화 기술
    • 구동 모듈의 크기가 작고 가벼움
  • 높은 집적도
    • 고밀도화 구성 가능
    • 낮은 사양에서 활용도 높음
  • 이동성
    • 자산의 Image를 클라우드 환경에 Import 가능
    • 유연한 확장 가능
  • 빠른 구동
    • 프로세스 실행 로직이 단축되어 빠른 구동/종료 가능
    • 운영체제가 포함되어있지 않으므로 부팅 절차가 생략되어 빠르고 가벼움
  • 일관적 구동 환경
    • 애플리케이션에 필요한 소프트웨어 종속 항목으로 일관성 구동 보장
  • 다양한 운영 환경 지원
    • 컨테이너 런타임의 다양한 OS 지원으로 구동 환경 다양성 지원
  • 독립환경
    • OS 수준에서 리소스 가상화 후 논리적으로 분리된 OS 샌드박스 환경 제공
  • 배포 편의성
    • 애플리케이션 종목 항목 버전 제어가 쉬워 민첩성, 생산성 향상

컨테이너와 쿠버네티스

컨테이너 운영의 고민

  • 배포 관리
    • 어떤 컨테이너를 어느 호스트에 배치하여 구동시킬 것인가?
    • 한정된 자원으로 최적의 스케줄링은?
  • 제어 및 모니터링
    • 구동중인 각 컨테이너들의 상태를 어떻게 추적하고 관리할 것인가?
  • 스케일링
    • 수시로 변화하는 운영 상황과 사용량 규모에 어떻게 대응할 것인가?
  • 네트워킹
    • 운영되는 인스턴스 및 컨테이너들을 어떻게 상호 연결할 것인가?
  • Containerized Infrastructure
    • 컨테이너에 해당하는 Image를 Update 하려면?
    • 컨테이너에 Auto Scale을 적용하려면?
    • 컨테이너가 동작 상태가 아닐 때 대처하려면?

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

컨테이너 오케스트레이션

  • 대규모 컨테이너들이 안정적으로 운영될 수 있도록 관리의 복잡성을 줄여주고 이를 자동화하는 것
  • 컨테이너가 실행되는 것 부터 컨테이너를 관리하는 것 까지가 컨테이너 오케스트레이션의 영역

  • 컨테이너 오케스트레이션 장점

    • 여러 컨테이너의 배포 프로세스 최적화
    • 컨테이너 자동 배치 및 복제
    • 컨테이너 그룹에 대한 로드 밸런싱
    • 컨테이너 장애 복구
    • 클러스터 외부에 서비스 노출
    • 컨테이너 추가 또는 제거로 확장 및 축소
    • 컨테이너 서비스 간의 인터페이스를 통한 연결 및 네트워크 포트 노출 제어

  • 컨테이너 관리의 필요성

    • On Demand Delivery
      • 필요한 컴퓨팅 자원을 즉시 제공
    • Consistency & Continuous
      • 이미지 기반 구성
      • 배포 효율화
      • 개발 운영환경 일관성
      • 배포된 이미지를 안정성 있게 보관해서 재배포 가능
    • Rolling Update
      • 업그레이드 및 패치 시 다운 타임 최소화
    • Self Recovery
      • 비정상 어플리케이션 및 장애 발생 시 정상 서버 노드 자동 재배치
    • Application Scaling
      • 애플리케이션 단위 오토스케일링
    • Portable
      • 멀티/하이브리드 클라우드 기반 운영

3. Kubernetes

공식사이트: https://kubernetes.io/

Kubernetes 구조

  • Cluster
    • Node 라고 불리는 머신들의 집합
    • 컨테이너 애플리케이션을 기동
    • Control Plane인 Master와 Worker Node로 구성됨
  • Node
    • 쿠버네티스 동작 머신 (가상 머신 또는 물리장비)
    • Pod들을 구동하기 위해 필요한 서비스 제공
      • 많은 컨테이너를 구동하기 위해서는 Node 자원이 많이 필요함
      • Node가 많아지면 Master에 부하가 일어날 수 있으므로 Master를 2개로 나누는 등의 조치가 필요할 수 있음
    • Control Plane에 의해 전체가 관리됨
    • Container Runtime Interface, kubelet, kube-proxy가 포함됨
  • Master (Control Plane)
    • 쿠버네티스 운영과 관련있는 컴포넌트 집합 세트
    • 클러스터 전체를 관리. 클러스터 상태를 컨트롤
      • 워커노드가 살아있는지, 얼마나 자원을 사용하고 있는지 정보를 주고받음
    • Worker-node에게 작업을 전달
      • 각각의 API 서비스 통신 서버를 사용
  • Worker Node
    • 컨테이너가 배포되는 머신
    • Control Plane에 의해 관리되는 실제 컨테이너 실행 기능 담당
    • kubelet + kube-proxy 서비스 실행

  • etcd
    • 모든 클러스터 데이터를 담는 쿠버네티스 운영 저장소
    • 분산형 키/밸류 오픈소스로 쿠버네티스 클러스터의 상태나 설정 정보를 저장
  • API Server
    • 쿠버네티스의 모든 명령과 통신을 위한 API 서버
    • Restful API 지원
  • Controller Manager
    • 컨트롤러를 생성하고 이를 각 노드에 배포하며 관리하는 역할
    • 컨트롤러는 노드, 레플리케이션, 엔드포인트, 서비스 어카운트 & 토큰을 관리하는 컨트롤러로 구성
  • kube-scheduler
    • Pod, 서비스 등 각 리소스들을 적절한 노드에 할당하는 역할
  • Cloud Controller Manager
    • 쿠버네티스와 Cloud Provider API와 연동하기 위한 컨트롤러를 생성하고 이를 각 노드에 배포하며 관리하는 역할
    • NHN Cloud IaaS 지원
  • Container Runtime
    • 쿠버네티스 Pod 내 구성된 컨테이너를 실행하는 기능 담당
    • 사용 컨테이너의 이미지 다운로드, 번들에서 압축 해제, 번들에서 컨테이너 실행 단계를 거침
    • Docker, Containered, CRI-O 등
  • kube-proxy
    • 클러스터 내 각 노드에서 실행되는 네트워크 프록시
  • kubelet
    • 클러스터 내 각 노드에서 실행되는 에이전트
    • Pod spec 정보 관리/운용 (생성, 삭제 등)

Kubernetes Resource

Kubernetes 작업 단위 구성

  • 쿠버네티스 서비스를 위해서는 한 개 이상의 Master와 한 개 이상의 Node가 필요함
    • 워커노드 안에서 컨테이너가 구동됨
  • 최소한의 작업 단위는 Pod이며, Pod를 복제본 단위로 그룹핑할 수 있는 것이 Deployment
  • k8s
    • 모든 기능을 사용하는 경우
  • k3s
    • 축약된 간단한 라이트한 구성
    • 마스터 역할을 하면서도 자신이 워커노드 역할을 할 수도 있음 (권장되지 않음)

Pod

  • 특징
    • 컨테이너를 그룹핑하여 관리 가능하며 서로간의 통신이나 업데이트 지원 가능
    • Pod 내 컨테이너는 IP와 Port를 공유
    • Pod 내에 배포된 컨테이너간 디스크 볼륨 공유 가능
    • 유형에 따라 Deployment, StatefulSet, DaemonSet으로 구성 가능
    • 자체 Pod를 생성하는 경우는 잘 없으며 보통 Deployment 형태로 배포
  • Pod 오브젝트 스펙
apiVersion: v1	# 쿠버네티스 API 버전
kind: Pod		# 리소스 종류 정의
metadata:		# Label, 리소스 이름 설정
  name: nginx
spec:			# 리소스 상세 스펙 정의
  containers:	# Pod는 컨테이너를 가지므로 container를 정의
  - name: nginx
    image: nginx:1.7.9	# nginx 이름으로 nginx 1.7.9 docker 이미지 사용
    ports:
    - containerPort: 8090	# 컨테이너 포트는 8090 오픈

Volume

  • 특징
    • 컨테이너 간 데이터를 공유하고 영속성을 제공하기 위한 기능
    • 컨테이너 내부의 파일 시스템과 유사한 방식으로 작동하며 컨테이너가 종료되어도 데이터 보존 가능
    • 컨테이너를 내리면 디스크의 내용이 모두 지워지지만, Pod 내의 컨테이너에서 사용하는 디스크를 따로 떼어내어 Volume으로 관리
    • Pod에서만 사용하거나, Worker Node에서 구성되는 파일 형태 그대로 마운트하거나(파드가 내려가도 워커노드에 파일이 남아있음), 외부 스토리지를 연결하는 등 가능
  • 종류

Service

  • 특징
    • 여러 Pod를 서비스하면서 이를 로드밸런싱하여 하나의 IP와 포트로 묶어 서비스 제공
      • 외부 사용자가 가상화되어 있는 서비스에 엔드포인트로 들어갈 수 있도록 함
    • Pod의 목록 지정 시 IP 주소를 유연하게 선택하기 위해 Label과 Label Selector 활용
  • 내/외부 통신을 위한 Service 종류
    • hierarchy를 가짐 (Cluster IP < Node Port < Load Balancer)
      • Load Balancer 타입 선택 시 Cluster IP, Node Port, Load Balancer 모두 가지게 됨

Namespace

  • 특징
    • 한 쿠버네티스 클러스터 내의 논리적 분리 단위
    • Pod, Service 등은 Namespace 별로 생성, 관리 가능하며 사용자 권한도 구별하여 부여 가능
  • 장점
    • 사용자 별 접근 권한 제어 가능
    • 리소스 할당량 (Quota) 지정 가능
    • 리소스 나누어 관리 가능 (Pod, Service 등)
  • 주의점
    • 논리적 분리 단위로 물리적, 기타 장치를 통해 환경을 분리한 것은 아님
      • 다른 Namespace 간 통신 가능
    • 보안이 높은 수준 운영을 위해서는 쿠버네티스 클러스터 자체를 분리하는 것을 권장

Controller

  • 어떤 Pod를 어느정도 자원을 가지고 몇 개의 복제본을 가지고 어디에서 실행시킬 지에 대해 설정

  • ReplicaSet (RS)

    • 사용자가 지정한 수의 Pod 복제본을 유지하는 역할

  • Deployment

    • Replication Controller와 ReplicaSet의 추상화 개념
    • ReplicaSet의 Rolling-update를 위해 deployment 사용
    • 애플리케이션의 배포를 관리
    • 사용자가 원하는 상태를 정의하고 새로운 버전의 애플리케이션을 배포하거나 롤백하는 등의 작업을 수행
    • 워커노드의 자원 할당에 따라 워커노드 상관없이 자유롭게 배포

  • StatefulSet

    • 상태를 가지는 애플리케이션을 관리
    • 특정 상태를 유지시킬 수 있도록 배포하는 경우
    • 각 Pod에 고유한 식별자를 할당하여 데이터의 안정적인 보존과 순서 유지

  • DaemonSet

    • 각 노드에 특정 Pod를 실행하는 역할
    • 노드 수에 따라 Pod를 자동으로 생성하고, 클러스터의 모든 노트에서 특정 작업을 수행 시 동작
    • 사전에 컨테이너 배포 전에 어떤 노드에서든 어떠한 서비스가 동작할 수 있도록하는 셋팅 서비스 (ex. 모니터링 등)

  • Secret
    • 클러스터 내에서 암호, 토큰, 비밀번호와 같은 민감한 정보를 안전하게 저장하기 위한 리소스
    • Base64로 인코딩되어 저장
      • 사용자가 값을 직접 확인할 수 없음
    • 주로 데이터베이스 비밀번호, API 토큰, 인증서와 같은 중요한 정보를 저장
  • ConfigMap
    • 클러스터 내에서 애플리케이션의 환경 변수, 설정 파일 등과 같은 구성 정보를 저장하기 위한 리소스
    • 애플리케이션의 동적인 구성 변경을 지원
    • 컨테이너 구동 시 ConfigMap의 내용을 불러와 대체해서 사용할 수 있음

Cluster 구성 관련 Document: https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/
Resource 관련 Document: https://kubernetes.io/docs/concepts/

Kubernetes Cluster 권장사항

Kubernetes Release

  • 쿠버네티스는 4개월에 한 번씩 버전업이 되고있음
  • EOL이 빨라 쿠버네티스 업데이트 및 유지하기 위해 클러스터 관리 담당자가 필요함
  • NKS 상품을 사용하면 버전업에 대해 신경쓰지 않아도 됨

Release 정보: https://kubernetes.io/releases/
Release Cycle: https://kubernetes.io/releases/release/
Patch release & EOL 정책: https://kubernetes.io/releases/patch-releases/#detailed-release-history-for-active-branches

Kubernetes Cluster Instance 사양

  1. k8s 호환(지원) 리눅스 머신
  2. 2 Core 이상 CPU, 2GB 이상 메모리 장착 머신 또는 가상화 Instance
    • 컨테이너 기반의 구동으로 자원 리소스가 많이 필요함
  3. 클러스터의 모든 머신에 연결 가능한 네트워크 환경
    • 공용, 사설 네트워크 환경, 특정 포트 사용 가능 환경
  4. 고유한 호스트 이름, MAC 주소, Product 고유 식별값(UID)를 갖는 노드 구성 머신 환경
  5. SWAP 기능 비활성화 환경

Kubernetes 사용 포트

  • Kubernetes에서 사용하는 Port와 Protocol

https://kubernetes.io/ko/docs/reference/ports-and-protocols/

NHN Kubernetes Service (NKS)

NHN Cloud 환경에 맞추어 Kubernetes를 활용할 수 있도록 만든 NHN Cloud 서비스

  • NHN Cloud 기반 서비스와 연동
  • 고가용성을 보장하는 Master Node 관리
  • 로그밸런서를 이용한 서비스 공개
  • 웹 콘솔을 이용한 쉬운 조작
  • 무중단 버전 업그레이드 지원

사용자 Kubernetes 설치 vs. NKS

사용자 설정NKS 설정
사용자가 인프라 자원 직접 구성 필요. 네트워크 설정, Security Group 설정 필요NKS에 자원을 지정하면 Compute Instance 부터 네트워크 관련 자원이 자동 생성됨
Master Node, Worker Node 직접 관리. 번거로운 Scale 관리Master Node를 외부 노출 없이 안전하게 관리. Worker Node를 웹 콘솔로 빠르게 관리 가능
별도의 Load Balancer 구성 및 설정 필요Service 구성을 통한 Load Balancer 생성 연동 자동화
구성 및 검증에 어느정도 시간이 소요됨구성 및 검증에 빠른 시간 소요
모든 설치 모듈 수동 진행클러스터 구성까지 Cloud 자원 설치 자동화
약 1시간 이상 소요30분 미만 소요
profile
hwwwa
이전 포스트

[Linux] rsync란? rsync 사용법 / rsync로 데이터 백업하기

다음 포스트

[기술세미나] Redis 운영 중에 발생할 수 있는 여러 가지 장애 Deep Dive (작성중)

post-custom-banner

0개의 댓글