Kubernetes

Kubernetes란?

쿠버네티스는 이동 가능 및 확장 가능한 오픈 소스 플랫폼으로, docker와 같이 컨테이너화된 워크로드나 서비스들, 설비들을 선언형(<-> 명령형) 설정과 자동화를 통해 관리하는 도구임. 핵심은 컨테이너 기반 작업의 자동화와 환경설정. 자주 사용되는 기능들을 모아 일반화, 추상화 시켜서 하나의 시스템으로 만든 것이라 보면 된다.

유사한 서비스(컨테이너 오케스트레이션)로는 도커 스웜, 메소스, 노마드 등이 있으나 오픈 소스화 등으로 업계에선 대부분 kubernetes를 사용함.

k8s(Kubernetes) Objects

k8s objects는 k8s 클러스터의 상태를 대표하는 쿠버네티스 내 추상적인 요소임. Pod, Service, Volume, Namespace 등 다양한 object가 있는데, 이것도 알아보자.

Pod

Pod는 k8s에서 생성하고 관리할 수 있는 배포 가능한 가장 작은 컴퓨팅 단위임. 하나 이상의 컨테이너가 포함되며, 공유 스토리지 및 네트워크 리소스와 컨테이너 실행 방법에 대한 사양이 포함되어 있음. 어플리케이션별 논리 호스트가 있음.

Deployment

Pod와 ReplicaSets에 대한 선언적 업데이트를 제공함. Deployment에서 원하는 상태를 명시하면, Deployment Controller는 실제로 해당 상태로 변경을 함. Deployment를 정의하여 새 ReplicaSet을 생성하거나 기존 Deployment를 제거하고 새로운 Deployment에 그 리소스를 할당할 수 있음.

참고로 레플리카셋(ReplicaSets)은 특정 Pod을 특정 개수만큼 복제한 집합으로, 로드 밸런싱 등을 위해 특정 개수만큼의 Pod 복제본을 안정적으로 유지하기 위한 개념임.

Service

Service는 클러스터에서 1개 이상의 Pods로 동작하고 있는 네트워크 어플리케이션을 외부로 노출시키기 위한 메소드임. Service를 통해 Pods들의 집합을 네트워크 상에서 사용자들과 상호작용하도록 만들 수 있음.

Deployment를 사용하고 있다면, Deployment는 Pod들을 동적으로 생성하거나 삭제함. 각 Pod들은 각각의 IP를 가지고 있는데, 이런 상황에서 하나의 Pod(frontend 등)이 다른 Pod(backend 등)으로 어떻게 접근을 유지할 수 있을까? (생성/삭제되는 ReplicaSets에서 가용한 것들의 IP를 동적으로 찾아줘야 함) => 이런 역할을 Service가 한다고 보면 된다.

Ingress

Ingress는 클러스터 내에서 서비스로의 외부 접근을 관리하는 API object임. 로드 밸런싱, 이름기반 가상 호스팅, SSL Termination 등을 제공할 수 있음. 라우팅을 하는 Object라고 생각하면 쉬울듯.

Namespace

Namespace는 단일 클러스터 내의 리소스 그룹을 격리하기 위한 메커니즘을 제공함(특정 리소스 그룹의 이름을 지정해주는 것). 네임스페이스 기반 범위 지정은 namespaced objects(Deployments, Services 등)에 대해서만 할 수 있고, 클러스터에 할당되는 objects(cluster-wide objects)(StorageClass, Nodes, PersistentVolumes 등)에는 지정될 수 없음.

(Worker) Node

kubernetes는 컨테이너를 Pods에 배치시켜 Nodes에서 실행되도록 해서 사용자의 작업을 수행함. Nodes는 클러스터에 따라 가상 머신일 수도 물리 머신일 수도 있는데, 각 노드는 Control Plane에서 관리되며, Pods 실행에 필수적인 서비스들을 포함하고 있음.

k8s 작업의 실제 실행 단위라고 보면 될듯.

일반적으로 클러스터엔 여러 개의 노드가 있으며, 노드 내의 컴포넌트로는 kublet, container runtime(pod들이 실행되는 곳), kube-proxy가 있다. 자세한 내용은 아래 그림 참고

Control Plane

위 그림은 k8s의 cluster architecture임. 하나의 클러스터는 하나의 Control Plane과 1개 이상의 Nodes를 가지며, Node의 모든 API 사용은 Control Plane의 API 서버로 감.

Control Plane은 현재 클러스터 상태를 사용자가 원하는 클러스터 상태로 끊임없이 조정해주는 컨트롤 센터임.

k9s

k9s란?

k9s란 터미널에서 쿠버네티스 클러스터를 사용하기 쉬운 UI로 관리할 수 있는 CLI 도구임. 쿠버네티스 리소스를 생성, 조회, 수정, 삭제할 때 kubectl 명령어를 사용할 수도 있지만, k9s를 사용하면 이 작업들을 더 편리하게 수행할 수 있다고 함. UI, 단축키, 자동완성 등의 부가기능도 제공.

k9s 사용법 익히기

공식 웹사이트 : https://k9scli.io/

Helm Chart

Helm이란?

Helm은 쿠버네티스 오픈 소스 패키지 매니저임. 쿠버네티스용으로 구축된 소프트웨어를 제공, 공유 및 사용할 수 있는 기능을 제공함.

chart라는 패키지 형식을 사용하며, chart는 쿠버네티스 리소스 집합을 설명하는 파일 모음임.
단일 차트를 사용해 memcached 파드같은 단순한 것 부터 HTTP 서버, 데이터베이스, 캐시 등이 포함된 전체 웹 앱 스택과 같은 복잡한 것도 배포할 수 있음.

chart는 하나의 디렉토리 내부에 파일 모음으로 구성되며, 디렉토리 이름이 각 chart의 이름임. npm, pip와 같이 helm chart를 저장하고 공유하는 데 사용할 수 있는 chart repository를 지원하는데, 대표적으로 Artifact Hub가 있다.

설치 및 사용

GitLab CI

CI, CD

CI란?

Continuous Integration. 지속적인 통합이라는 의미.

새로운 코드 변경 사항이 정기적+자동으로 빌드 및 테스트되어 공유 레포지토리에 통합되는 것을 의미함.
다수의 개발자들이 형상관리 툴을 관리할때 주로 사용되며, 새로운 코드의 빌드, 테스트, 병합(merge)하는 기능이 포함됨.

CD란?

Continuous Delivery 또는 Continuous Deployment. 지속적인 제공 또는 지속적인 배포라는 의미.

CI에서 빌드/테스트/병합된 코드가 배포를 함에 있어 문제가 없는지 검증한 후 배포를 수동적으로 진행하는 것이 Continuous Delivery, 배포 과정까지 자동으로 진행하는 것이 Continuous Deployment이다.

GitLab CI/CD란?

GitLab CI/CD는 애플리케이션 구축, 테스트 및 배포 프로세스를 자동화하는 GitLab의 기본 제공 기능임.

• GitLab 홈페이지
• GitLab CI/CD 공식문서

문법은 다소 다르지만 GitHub Actions와 동작 방식은 유사하다고 볼 수 있겠다(YAML 파일에 정의된 파이프라인대로 단계별 작업 실행)

주요 기능과 동작 방식은 위 그림과 같으며, 관련된 주요 개념은 다음과 같음.

• 구성(Configuration) : Git 리포지토리의 루트 디레토리에 저장된 .gitlab-ci.yml이라는 YAML 파일을 사용하여 환경 설정을 할 수 있음. 빌드, 테스트 및 배포 프로세스를 설명하는 다양한 작업, 단계 및 규칙을 정의함.
• 파이프라인(Pipeline) : 커밋이 Git 리포지토리로 푸시되거나 병합 요청이 생성되면 GitLab CI/CD가 자동으로 파이프라인을 트리거함. 파이프라인은 .gitlab-ci.yml에 정의된 대로 실행됨.
• 작업(Jobs) : 파이프라인 내의 개별 작업 단위. 각 작업은 .gitlab-ci.yml에 정의되어 있음.
• 단계(Stage) : 빌드, 테스트 및 배포와 같은 파이프라인의 여러 단계. 동일한 스테이지 내의 작업은 병렬로 실행되며, 스테이지는 순차적으로 실행됨. 구조화된 방식으로 파이프라인을 구성하고 시각화하는 가독성 측면에서도 도움됨.

예시

학습메모 10 예시. 대략 아래와 같은 식이다. gradle을 사용한 Java 프로젝트 빌드 및 도커 이미지 생성.

stages:
  - build
  - dockerbuild-push

build:
  image: openjdk:11.0-slim
  stage: build
  script:
    - ./gradlew clean
    - ./gradlew build -x test
  before_script:
    - chmod +x gradlew
  artifacts:
    paths:
      - build/libs/*.jar
    expire_in: 8 min

package:
  image: docker:latest
  stage: dockerbuild-push
  services:
    - docker:dind
  before_script:
    - docker login registry.gitlab.com -u $GITLAB_USER -p $GITLAB_PW
  script:
    - docker build -t registry.gitlab.com/$GITLAB_USER/<project-name> .
    - docker push registry.gitlab.com/$GITLAB_USER/<project-name>
  after_script:
    - docker logout

AWS

AWS란?

AWS(Amazon Web Services)는 amazon.com에 제공하는 클라우드 컴퓨팅 플랫폼을 구성하는 원격 컴퓨팅 서비스들의 집합임. 클라우드 컴퓨팅 플랫폼 서비스를 처음 시작하여 현재까지도 압도적인 세계 1위 점유율을 유지중(업계 표준).

VPC

Amazon Virtual Private Cloud. AWS의 가상 사설 네트워크로, AWS에서 생성되는 대부분의 인스턴스들은 기본적으로 이 VPC를 통해 네트워크에 연결된다.

위 그림은 VPC 구성의 예시이다.

다시 말해 VPC는 사용자의 AWS 계정 전용 가상 네트워크 망으로, 리전별로 부여되는 리전 서비스이다.

VPC -> VPC에서 VPC를 생성하고 관리할 수 있음. CIDR 블록으로 IP 범위 지정.

Subnet

Sub Network. VPC를 더 작은 범위의 네트워크로 나눈 것으로, VPC와 달리 AZ 서비스이다.

VPC -> 서브넷에서 서브넷을 생성하고 관리할 수 있음. VPC를 지정하고 CIDR 블록으로 IP 범위 지정.

라우팅 테이블

네트워크 트래픽 전달 규칙을 정의하는 테이블. Subnet별로 라우팅 테이블을 정의하여 Destination(IP범위)으로 향하는 트래픽이 어떤 Target(local, GW 등)으로 전달될지를 지정한다.

CIDR 블록

AWS에서는 CIDR 표기법을 통해 VPC, Subnet 등의 IP 주소 범위를 지정할 수 있다.

CIDR 표기법은 네트워크 식별자 비트를 지정된 형식으로 나타내는 IP 및 접미사로, 예를 들어 192.168.1.0을 22비트 네트워크 식별자를 사용하여 192.168.1.0/22로 표현할 수 있다.

Security Group (SG)

보안 그룹. 인스턴스의 inbound/outbound 트래픽 제어에 사용. 기존의 방화벽(FW)과 유사한 용도.

유사하게 Subnet의 트래픽을 allow/deny할 수 있는 NACL이 있으며, 기존 라우터의 ACL과 유사한 용도임. 간단한 규칙은 NACL을 통해, 인스턴스별 세부 규칙은 보안 그룹을 통해 여러 단계로 접근을 제어함.

EC2 -> 보안 그룹에서 inbound/outbound별로 프로토콜, 포트 범위, 소스IP 범위를 지정할 수 있음.

EC2

Amazon Elastic Computing Cloud. 안전하고 확장 가능한 컴퓨팅 서비스로, "인스턴스(Instances)"라는 형태로 배포됨. 가장 대표적인 AWS 서비스로, 어플리케이션을 클라우드상에 배포하고 운영하기 위한 서버 역할을 함.

사용한 만큼 (초당으로) 요금을 지불하고, ELB, Auto Scaling, S3등 다양한 서비스와 연동됨.

EC2 -> 인스턴스에서 인스턴스명, OS 및 인스턴스 유형(하드웨어 스펙) 지정, 키페어 지정, 네트워크 설정(VPC, 서브넷, SG 등), 스토리지 지정 등을 통해 인스턴스를 생성 및 관리할 수 있으며, 지정된 키페어와 외부IP 등록으로 SSH 등으로 외부 접근하여 관리할 수 있음.

S3

Amazon Simple Storage Service. 객체 스토리지. 서버에 사용되는 파일의 업로드, 다운로드, 검색 기능을 제공함. 무제한 용량으로 사용량에 따라 요금을 부과함.

다양한 인증/권한 부여 기능도 제공하며, 통상적으로 AWS-SDK에서 제공하는 API 형태로 접근해서 (게시판의 이미지 등) 사용자 파일을 업로드, 다운로드 및 검색하는 등으로 활용함.

리전 기반 서비스이며, 매우 안전(백업 카피가 많아 데이터 손실 위험이 낮음), CDN과 연동 가능, static web page 기능 지원 등의 특징을 지니고 있음.

Amazon S3 -> 버킷에서 AWS 리전 설정, 버킷 이름 설정하여 버킷을 생성 및 관리할 수 있으며, 이 리전과 버킷 이름으로 외부에서 접근 가능.

ArgoCD

GitOps란?

기존의 소프트웨어 배포 및 관리 방식은 인프라 환경을 수동으로 관리해야 했기에 문제가 많았음. 소프트웨어 형상과 인프라를 따로 관리해야 했으며, 이로 인해 인프라와 소프트웨어 개발환경 간의 불일치로 배포 및 운영 과정에서 사람의 실수로 문제가 발생할 가능성이 높았던 것.

이러한 기존 방식에 대한 대안으로 GitOps가 탄생함.

GitOps는 Git 저장소를 사용하는 소프트웨어 배포 접근 방식으로, 인프라와 소프트웨어를 함께 관리하기 때문에 운영 환경의 일관성을 유지함. 또한 모든 코드 및 인프라 변경 사항이 Git 저장소에 저장되기 때문에 변경 내역을 추적/롤백하기가 유용함.

좀 더 정확하게, GitOps라는 용어는 Cloud Native 프로젝트에 DevOps를 어떻게 적용할 지에 대한 실천적 방법론임. 통상 Kubernetes 환경에서 Continuous Deployment를 수행하기 위한 원칙이자 방법론이며, IaC(Infrastructure as a Code), 즉 인프라를 코드로 표현하는 도구들을 활용해 이를 구현할 수 있음.

ArgoCD란?

ArgoCD는 이러한 GitOps를 구현하기 위한 도구 중 하나로, Kuberenetes 애플리케이션의 자동 배포를 위한 오픈소스 도구임. Git 저장소에서 변경 사항을 감지하여 자동으로 Kubernetes 클러스터에 애플리케이션을 배포(변경사항을 적용)할 수 있는 기능을 제공함.

동작 방식은 위 그림과 같음. Git 변경을 감지하여 Kubernetes 배포 방식인 Helm 등으로 배포.
여기서 말하는 Git 저장소는 Helm 차트 프로젝트의 리포지토리를 말함.

Datadog

Datadog이란?

상태 데이터를 수집하고 관리하기 위한 모니터링 도구임. 유사한 모니터링 데이터 수집 도구로는 프로메테우스, 인플럭스DB, 뉴 렐릭 등이 있음.

• Datadog 홈페이지

학습 메모

1. kubernetes overview
2. kubernetes pod
3. kubernetes networking concepts
4. kubernetes cluster architecture
5. k9s with minikube
6. helm이란?
7. GitLab CI/CD란? 1
8. GitLab CI/CD란? 2
9. GitLab CI/CD란? 3
10. GitLab 파이프라인 설정하기
11. GitLab CI/CD vs. GitHub Actions
12. GitLab CI/CD -> GitHub Actions 마이그레이션
13. ArgoCD란? 1
14. ArgoCD란? 2
15. 데이터독이란?
16. 데이터독 소개 ppt
17. 실습으로 배우는 AWS 핵심 서비스(인프런)
18. AWS