Kubernetes 4일차 개념 정리

What is CloudNative

 

• 확장성
  • 하나의 숫자로 표시될 수 있는 것 → Metric
  • 쿠버네티스는 Metric 기반 리소스 운영

→ 쿠버네티스는 CPU, 메모리, 사용자 정의 메트릭 등을 기반으로 오토스케일링을 수행

• 회복성
  • 선언적(Declarative) 정의!!
  → 사용자가 “원하는 상태(state)”를 정의하면, 쿠버네티스가 실제 상태를 자동으로 그에 맞춤
• → Pod가 죽으면 자동으로 재시작되거나 교체됨
• 관리 편의성
  • 컨테이너? 변경관리 최소화(immutable system) → 아무리 변경을 해도 원래대로 돌아감(가장 중요한 포인트!!!) → 모든 장애의 99%는 변경으로 발생
• 자동화
  • 쿠버네티스는 API가 굉장히 잘 지원됨
  • 자동화는 API로 이루어진다!!! → kubectl, client-go, controller, operator 등이 API와 직접 통신

 

<4 Layers Of Cloud-Native>

• DevOps
  • 개발 생산성 향상
  • 자동화된 시스템이 안정되게 돌아가도록 하는 것
• CD / CD
• Container
• Open Source

 

 

Helm Chart

 

Helm Chart: 애플리케이션을 쿠버네티스에 배포하기 위한 템플릿 기반 패키지 시스템

→ Helm은 마치 apt, yum, npm처럼 "앱 배포용 패키지 관리자" 느낌

 

 

 

• Helm으로 mysql 설치한 모습

 

Kustomize? → 환경별 YAML 패치

• 변경되는 환경마다 yml 파일을 패치할 수 있게 해줌

Helm 차트? → 애플리케이션 패키징 & 배포 자동화

• 소프트웨어를 패키징 할 용도로 자주 사용
• 패키징한 것을 차트라 부름
• 내가 만든 소프트웨어의 환경 변수, 설정 기타 등등 들에 대하여 변경 가능한 인터페이스를 제공

둘이 같이 사용할 순 있으나 그러지 않는 것을 권장

 

 

나만의 helm chart 만들기

 

 

 

1. Chart.yaml

apiVersion: v2
name: nginxstd
description: nginx standard for subin company
type: application
version: 1.0.0 # 차트 버전
appVersion: "1.27.0" # 애플리케이션 버전

• 역할: Helm Chart의 메타데이터를 정의하는 파일
• 내용: 이름(name), 설명(description), 버전(version), 앱 버전(appVersion) 등
• 의미: 이 Helm Chart가 어떤 배포 단위인지 정의
• 📍 “패키지 이름표”

---

2. values.yaml

environment: development
container:
  name: nginx
  port: 80
  image: nginx
  tag: latest
replicas: 2

• 역할: 사용자가 커스터마이징할 변수들을 설정하는 파일
• 내용: 환경(environment), 컨테이너 이름, 포트, 이미지 등
• 의미: .Values.key 형태로 템플릿 파일에서 참조됨
• 📍 “변수 설정 파일 (사용자 입장에서 수정 대상)”

---

3. templates/deployment.yml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Values.container.name }}
spec:
  replicas: {{ .Values.replicas }}
  selector:
    matchLabels:
      app: {{ .Values.container.name }}
  template:
    metadata:
      labels:
        app: {{ .Values.container.name }}
        environment: {{ .Values.environment }}
    spec:
      containers:
        - name: {{ .Values.container.name }}
          image: {{ .Values.container.image }}:{{ .Values.container.tag }}
          ports:
            - containerPort: {{ .Values.container.port }}
          env:
            - name: environment
              value: {{ .Values.environment }}

• 역할: Kubernetes Deployment 리소스를 생성하는 템플릿
• 내용: .Values 값을 참조해 컨테이너 정보, replica 수, 포트 등을 설정
• 의미: 실제 애플리케이션 Pod를 정의하고 생성
• 📍 “애플리케이션 실행 본체 정의”

---

4. templates/service.yaml

apiVersion: v1
kind: Service
metadata:
  name: {{ .Values.container.name }}-service
  labels:
    app: {{ .Values.container.name }}
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: {{ .Values.container.port }}
  selector:
    app: {{ .Values.container.name }}
  type: LoadBalancer

• 역할: 서비스(Service) 리소스를 정의하는 템플릿
• 내용: 외부 노출용 LoadBalancer 설정 포함, 포트 정보 지정
• 의미: 외부에서 접근 가능한 엔드포인트 설정
• 📍 “서비스 엔드포인트 정의”

 

5. Helm 명령어 흐름

 

➤ Helm Chart 생성

helm create nginxstd

• 디렉토리 구조 자동 생성됨 (Chart.yaml, values.yaml, templates/ 등)

➤ Helm Chart 설치 (로컬)

helm install nginxstd ./nginxstd

• 로컬 Helm Chart를 바로 설치 (기본 values.yaml 사용)

 

6. Helm Chart 패키징 및 배포 흐름

 

➤ Helm Chart 압축 (패키징)

helm create nginxstd

 

• nginxstd-1.0.0.tgz 생성됨

➤ Helm Chart 저장소(Repo) 준비

mkdir prod mv nginxstd-1.0.0.tgz ./prod helm repo index ./prod

• prod 폴더가 Helm 저장소로 역할 수행
• index.yaml이 생성되어 chart 정보를 갖게 됨

➤ GitHub 저장소에 업로드

git init git remote add origin <git-repo> git push origin main

• GitHub Pages 기반 Helm 저장소로 구성 가능

 

7. Helm 저장소 등록 및 설치

 

➤ 저장소 등록

helm repo add helm-prod https://.../helm-off-repo/

 

 

➤ Chart 검색

helm repo update
helm search repo nginxstd

 

 

➤ 저장소에서 설치

helm install nginxstd helm-prod/nginxstd

• Helm 저장소에 등록된 Chart로 설치

 

8. stage-values.yml로 업그레이드 (Override)

 

➤ 커스텀 values 파일로 업그레이드

helm upgrade -f ./stage-values.yaml nginxstd helm-prod/nginxstd

• replicas, container.name 등의 설정을 변경하여 배포 상태만 업데이트

 

 

 

최종 구성도 요약 (Flow)

[Chart.yaml] ← Helm Chart 이름표
   ↓
[values.yaml] ← 사용자가 설정할 값
   ↓
[templates/...] ← deployment, service 등의 리소스 템플릿
   ↓
helm install ./ → 쿠버네티스에 적용
   ↓
helm package → Helm 저장소 등록용 tgz 생성
   ↓
GitHub Pages 등으로 Chart 저장소 구성
   ↓
helm repo add → Helm 저장소 등록
   ↓
helm install helm-prod/nginxstd → 저장소에서 설치
   ↓
helm upgrade -f ./stage-values.yaml nginxstd helm-prod/nginxstd → 설정 변경 후 재배포

 

 

 

CI / CD

Continuous Integration (CI): 개발자가 해야 할 자동화 영역

1. 코드 빌드
2. 테스트 수행 (유닛 테스트 → EtoE 테스트 → 부하 테스트)
3. 보안 분석(vulnerability, 취약점)
4. 코드 리뷰 & 코드 컨벤션
5. 산출물 생성(요즘 CI의 산출물 = 이미지)

 

Continuous Delivery(CD): 거의 자동이지만, 최종 배포는 수동으로 승인 / 운영환경 배포 직전까지 자동화된 상태

Continuous Deployment (CD): 완전 자동으로 배포까지 진행됨 (승인 없이 운영 반영)

 

 

<AWS 기반 CI/CD 구성>

 

1. AWS CodeDeploy → CD (Continuous Delivery)

• 역할: 최종 애플리케이션을 운영 환경에 배포하는 도구
• 사전 조건:
  • 배포 대상 애플리케이션을 .zip 또는 .tar 형식으로 압축해야 함
  • S3 버킷 또는 GitHub 등에 업로드 필요
  • appspec.yml 파일 필수 포함
    → 이 파일은 배포 중 실행할 스크립트(예: shell)와 파일 배치 경로 등을 정의
    → CodeDeploy Agent가 이를 읽고 배포 수행

2. AWS CodePipeline → CI (Continuous Integration)

• 역할: 빌드부터 테스트, 배포까지 전체 흐름을 자동화하는 파이프라인 관리 도구
• Git commit → Build (CodeBuild) → Deploy(CodeDeploy) 흐름 구성 가능

 

개발자 Git Push
     ↓
[CodePipeline (CI)]
     ↓
[CodeBuild] → 빌드, 테스트 수행
     ↓
[CodeDeploy (CD)]
     ↓
운영 서버에 자동 배포

 

 

 

CI/CD 도구

• Github Action() - 패치를 매일 하므로 제일 안전함 / 선언형(추상화)*
• Gitlab runner - 패치를 거의 하지 않으므로 취약점 다량 발생 / 선언형
• Jenkins - 해킹 자주당함 / 실제 현업에서 자주씀 / 스크립트로 짜므로 명령형
• CircleCI pipeline - 오픈소스 프로젝트에 사용
• BitBucket pipeline - 잘 안씀

CD 전문 도구

→ 요즘은 CI 도구와 CD 도구를 따로 씀!!

• ArgoCD() - 중간정도의 성능*
• Spinnaker(*) - 대규모 조직에서 사용, 기능이 너무 많음
• fluxCD() - 굉장히 심플**
• JenkinsX

 

클라우드 기반 CI/CD 구축

 

GitHub Actions: GitHub에서 제공하는 워크플로우 자동화 도구

 

• 리포지토리 내부 또는 외부에서 발생하는 이벤트에 대해 반응할 수 있음
• 해당 이벤트에 대응하는 워크플로우를 실행 가능

GitHub Actions 주요 환경변수

변수	설명
$GITHUB_WORKSPACE	STEP에 대한 Runner Machine의 기본 작업 디렉토리 및 체크아웃 작업을 사용할 때 기본 위치
$GITHUB_REPOSITORY	소유자 및 리포지토리 이름 (예: dangtong76/actions)
$GITHUB_ACTOR	워크플로를 시작한 사람 또는 앱의 이름
$GITHUB_SHA	워크플로우를 트리거한(호출) Commit 의 해쉬값
$GITHUB_REF	워크플로우를 트리거한(호출)Git 참조 (브렌치 또는 태그)의 전체 경로 브랜치 : refs/heads/ 태그 : refs/tags/

 

 

Workflow: 워크플로우는 특정 이벤트가 발생했을 때 실행되는 자동화된 작업의 집합

• 누군가 push를 하면?
• 새로운 pull request가 생기면?

→ GitHub Actions는 이를 자동 감지하고, 지정된 워크플로우를 자동 실행

 

📦 Workflow
 ┣ 📂 하나 이상의 Job
 ┃   ┣ ⚙️ 여러 개의 Step
 ┃   ┣ Step1 → Step2 → Step3 ...
 ┣ 이벤트가 발생하면 → 순차적으로 실행

 

• Workflow: .github/workflows/*.yml 파일로 정의
• Job: 병렬 또는 순차적으로 실행되는 작업 단위 (예: Build, Test, Deploy)
• Step: 실제로 쉘 명령어 또는 액션(action)을 실행하는 세부 단계
• Runner: 각 Job을 실행할 머신 (GitHub 제공 or 직접 호스팅)

 

<Git Workflow 예시>

## .github/workflows/ec2-deploy-smart.yml
name: AWS EC2-Deploy with Smart
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: 1.소스코드 다운로드 (simple-web)
        uses: actions/checkout@v2

      - name: 2.AWS CLI 접속정보 설정
        uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ap-northeast-2

      - name: 3.아티팩트 만들기
        run: |
          pwd
          zip -r deploy.zip ./*

      - name: 4.S3 아티팩트 업로드
        run: |
          aws s3 cp deploy.zip s3://${{ secrets.AWS_BUCKET }}/deploy.zip

      - name: 5.현재 진행중인 AWS Deploy ID 가져오고 중단 시킨다.
        run: |
          DEPLOYMENTS=$(aws deploy list-deployments \
            --application-name simple-web-content \
            --deployment-group-name simple-web-deploy-group \
            --include-only-statuses "InProgress" \
            --query 'deployments[]' \
            --output text)

          if [ ! -z "$DEPLOYMENTS" ]; then
            for deployment in $DEPLOYMENTS; do
              echo "Stopping deployment $deployment"
              aws deploy stop-deployment --deployment-id $deployment
            done
            # 잠시 대기하여 취소가 완료되도록 함
            sleep 10
          fi

      - name: 6. AWS Deploy를 통해 배포한다
        id: deploy
        run: |
          DEPLOYMENT_ID=$(aws deploy create-deployment \
            --application-name simple-web-content \
            --deployment-group-name simple-web-deploy-group \
            --s3-location bucket=${{ secrets.AWS_BUCKET }},key=deploy.zip,bundleType=zip \
            --output text \
            --query 'deploymentId')
          #echo "::set-output name=deployment_id::$DEPLOYMENT_ID"
          #echo "{name}=deployment_id" >> $GITHUB_OUTPUT
          echo "deployment_id=${DEPLOYMENT_ID}" >> $GITHUB_OUTPUT

      - name: Wait for deployment to complete
        run: |
          aws deploy wait deployment-successful --deployment-id ${{ steps.deploy.outputs.deployment_id }}

 

 

Runner: 워크플로우를 실행시키는 실행 환경

 

• GitHub Hosted Runner: GitHub에서 제공 (Ubuntu, Windows, macOS 등 미리 설치됨)
• Self Hosted Runner: 직접 서버를 등록하여 실행 (유료 인프라나 사내 환경 사용 시 활용)

 

 

 

ArgoCD

 

ArgoCD: GitHub에 있는 쿠버네티스 설정을 자동으로 감시하고 클러스터에 반영해주는 GitOps 기반 CD 도구.

 

• GitOps 방식으로 Kubernetes에 애플리케이션을 자동 배포해주는 도구
• GitOps: Git 저장소(GitHub 등)에 정의된 상태(예: *.yaml 파일)를 기준으로, 쿠버네티스 클러스터를 자동으로 동기화하여 배포하는 방식
• 즉, Git 저장소에 있는 Kubernetes 설정파일이 곧 진짜 클러스터 상태가 되도록 유지
• GitHub은 설정 보관소 /  Kubernetes는 실행 환경 / ArgoCD는 감시 + 자동 배포기
  (AWS CodeDeploy는 VM에 맞는 자동 배포기)
  • GitHub에 *.yaml 파일(push)만 하면,
  • ArgoCD가 이를 자동 감지해 → Kubernetes에 적용
  • GitHub은 설정 저장소 역할, ArgoCD는 자동 적용기 역할

 

 

최종 실습 환경

개발자 PC
│
Container
├─ CodeServer 
|- 웹 VSCode → simple-web 개발
		└─ git push
       ↓
GitHub Actions (simple-web/.github/workflows)	-> 개발자가 작업 / push
(eks-deploy-very-smart.yml)
->  Kubernetes 배포 파일(simple-web-deploy.yml) 안에 
정의된 Docker 이미지 태그를 최신 태그로 자동 수정

├─ Docker 이미지 빌드 및 Push (Docker Hub)
|
└─ simple-web-platform 리포지토리 배포 파일 수정됨(Tag) -> ArgoCD가 감시 / 배포 실행
       ↓
GitHub (simple-web-platform)
│
└─ manifest 변경 → ArgoCD 감지
       ↓
ArgoCD (EKS Cluster, argocd namespace)
│
└─ EKS default namespace에 배포
       ↓
EKS
├─ Deployment (simple-web)
├─ Service (LoadBalancer)
└─ Ingress (ALB)
       ↓
사용자 브라우저 (ALB 주소로 접근)