Kubernetes를 처음 공부하면 가장 헷갈리는 부분이 Control Plane과 Data Plane의 역할 차이다.

minikube로 실습하면서 구조를 직접 확인해보고 나서야 전체 그림이 정리됐다.

Kubernetes는 크게 다음 2가지 영역으로 나뉜다.

Control Plane (Master Node)
Data Plane (Worker Node)

1. Control Plane (Master Node)

클러스터 전체를 통제하고 관리하는 영역 “두뇌 역할”을 한다고 보면 된다.

1-1 .kube-apiserver

✔ Kubernetes의 모든 요청이 들어오는 관문(Gateway)

✔ kubectl 명령어도 결국 API Server로 요청을 보낸다.

→ kubectl → kube-apiserver → etcd 조회 → 결과 반환

즉, 모든 컴포넌트는 직접 통신하지 않고

반드시 kube-apiserver를 통해서만 통신한다.

Kubernetes의 “중앙 통제 허브”

1-2. etcd

✔ 클러스터의 모든 상태 정보 저장소 (Key-Value DB)

✔ 분산 환경에서도 일관성 보장

저장되는 정보 예:

• Pod 정보
• Deployment 설정
• Service 설정
• ConfigMap / Secret

중요한 점:

Kubernetes는 “현재 상태”가 아니라

“원하는 상태(Desired State)”를 etcd에 저장한다.

그리고 이 상태를 맞추기 위해 컨트롤러들이 계속 동작한다.

1-3. kube-scheduler

✔ 새로 생성된 Pod를

✔ 어떤 Worker Node에 배치할지 결정

기준:

• CPU / Memory
• Node 리소스 상황
• Taints / Tolerations
• Affinity / Anti-affinity

ex) 3개의 Pod를 → 어떤 노드에 배치할지 판단하는 게 Scheduler 역할

1-4.kube-controller-manager

✔ 클러스터 상태를 지속적으로 감시

✔ “현재 상태”와 “원하는 상태”를 맞추는 역할

예:

• ReplicaController
• DeploymentController
• NodeController
• JobController

예시 상황:

Pod 3개 유지해야 하는데 1개가 죽었다

→ Controller가 감지

→ 새 Pod 생성

→ 상태 복구

1-5.cloud-controller-manager

✔ AWS, GCP 같은 클라우드 환경 연동 담당

✔ LoadBalancer, Volume, Node 연동 처리

minikube에서는 거의 체감이 없다.

EKS 같은 환경에서 중요해진다.

2.  Data Plane (Worker Node)

실제 애플리케이션이 배포되는 영역 “몸통 역할”

2-1.kubelet

✔ 각 Worker Node에서 실행

✔ Control Plane과 통신

✔ Pod 실행 및 상태 보고

kubelet은 다음을 수행한다:

• API Server에서 Pod 스펙을 받아옴
• Container Runtime에게 컨테이너 실행 요청
• Pod 상태를 API Server에 보고

즉, 노드의 대리인 역할.

2-2. container runtime

✔ 실제로 컨테이너를 실행하는 엔진

예:

• containerd
• CRI-O
• (예전에는 Docker)

minikube에서는 보통 containerd 사용

흐름: kubelet → container runtime → 컨테이너 실행

2-3 kube-proxy

✔ 네트워크 라우팅 담당

✔ Service가 Pod로 트래픽을 전달할 수 있도록 처리

흐름 

Service (ClusterIP)
   ↓
kube-proxy가 iptables/ipvs 설정
   ↓
실제 Pod로 트래픽 전달

Service가 Pod를 직접 찾는 게 아니라

kube-proxy가 네트워크 규칙을 만들어주는 구조다.

전체 흐름 정리

Pod를 하나 생성한다고 가정해보자.

kubectl apply -f deployment.yaml

1️⃣ kubectl → kube-apiserver

2️⃣ apiserver → etcd에 desired state 저장

3️⃣ scheduler → Pod를 어느 노드에 배치할지 결정

4️⃣ kubelet → container runtime에게 실행 요청

5️⃣ kube-proxy → 네트워크 설정

6️⃣ Controller → 상태 계속 감시

이 모든 과정이 자동으로 돌아간다.

쿠버네티스(Kubernetes)는 컨테이너화된 애플리케이션을 자동으로 배포, 스케일링, 운영해주는 오픈소스 플랫폼입니다. 처음 접하면 용어와 개념이 낯설 수 있지만, 기초부터 차근차근 익히면 효율적으로 활용할 수 있습니다. 이번 글에서는 초보자를 위한 쿠버네티스의 핵심 개념 7가지를 소개합니다.

쿠버네티스 환경 실습및 학습을 위해  GCP  90일 무료 크레딧을 통해  진행할 수 있다.

1. kubectl – 쿠버네티스와 대화하는 터미널 도구

kubectl은 쿠버네티스를 조작할 수 있는 커맨드라인 도구입니다. 마치 서버 관리자와 대화하는 창구 역할

kubectl get pods
kubectl apply -f deployment.yaml
kubectl describe node <노드이름>

쿠버네티스 클러스터에 명령을 보내 리소스를 생성하거나 상태를 조회할 수 있다.

2. Label – 리소스를 구분짓는 이름표

label은 쿠버네티스의 리소스(Pod, Node 등)에 붙이는 키-값 쌍입니다. 이걸 이용하면 리소스를 그룹화하거나 특정 기준으로 검색할 수 있다.

--  yaml  설정중  label  예시

labels:
  app: myapp
  env: production

이렇게 라벨을 붙여두면 원하는 Pod를 효율적으로 찾아서 작업이 가능

3. Selector – 라벨로 리소스를 찾는 방법

selector는 위에서 설명한 label을 기준으로 리소스를 선택하는 방법입니다. 대표적으로 ReplicaSet이나 Service가 Selector를 통해 연결 대상을 찾는다.

selector:
  matchLabels:
    app: myapp

즉, app=myapp 라벨이 붙은 Pod를 대상으로 동작

4. Node – 쿠버네티스 클러스터의 일꾼

Node는 실제 애플리케이션이 실행되는 서버이다. 쿠버네티스 클러스터는 하나 이상의 Node로 구성되어 있으며, 각 Node는 여러 Pod를 실행할 수 있다.

kubectl get nodes

명령어로 클러스터에 어떤 Node가 있는지 확인가능

5. nodeSelector – 특정 노드에 Pod 배치하기

기본적으로 쿠버네티스는 적절한 Node를 자동으로 선택하지만, 특정 Node에 Pod를 배치하고 싶을 때는 nodeSelector를 사용

spec:
  nodeSelector:
    disktype: ssd

이 설정을 통해 disktype=ssd 라벨이 붙은 Node에만 Pod가 배치

6. Replica – 애플리케이션의 복제 개수

애플리케이션의 안정성과 확장성을 위해 같은 Pod를 여러 개 복제할 수 있습니다. 이 개수를 설정하는 것이 바로 replicas

spec:
  replicas: 3

위와 같이 설정하면 동일한 Pod가 3개 실행되며, 하나가 죽어도 나머지가 서비스를 유지

7.YAML – 쿠버네티스 리소스 정의 파일

쿠버네티스에서 리소스는 주로 YAML 파일로 정의됩니다. 사람이 읽기 쉬운 구조이며, 선언형 방식으로 리소스의 상태를 명시한다.

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mycontainer
    image: nginx

YAML은 리소스를 생성할 때 매우 중요한 포맷

쿠버네티스라는것을 사용할때 기본적으로 속성으로 알고 가면 좋을것들을 정리해 봤는데 두서 없이 정리하다보니  아쉽지만 보통 구축된 곳을가면 가장 신경?을 많이써서 보는곳이  replica 관련 속성이다. 이와 관련 된 부분을 잘 보면 좋을것 같다.

마이크로서비스 아키텍처에서는 하나의 요청이 여러 서비스를 거쳐 처리됩니다. 이때, 특정 서비스에서 오류가 발생하면 단순히 로그만으로는 문제의 근본 원인을 파악하기 매우 어렵다. Jaeger의 트레이스 데이터로 전체 흐름을 파악하고, Kibana의 상세 로그로 특정 시점의 오류를 분석할 수 있다면 디버깅 시간을 획기적으로 줄일 수 있다.

로컬 테스트를 하기위해 docker compose 를 활용하여 실행 예정(docker desktop)

아래는  contianer 실행 및 임시로 만든 서비스로  호출 테스트를 진행하는 부분이다.

1. 목표 아키텍처 

• OpenTelemetry로 애플리케이션의 트레이스 데이터와 로그를 생성합니다.
• Jaeger는 트레이스 데이터를 수집하여 Elasticsearch에 저장합니다.
• Filebeat는 애플리케이션 로그 파일을 읽어 Elasticsearch로 전송합니다.
• Kibana를 통해 Elasticsearch에 저장된 트레이스(Jaeger)와 로그(Filebeat) 데이터를 통합하여 분석합니다.

2. Docker compose 구성

모든 컴포넌트를 로컬에서 쉽게 실행할 수 있도록 docker-compose.yml 파일을 작성

이 파일은 Elasticsearch, Kibana, Jaeger, OpenTelemetry Collector, 그리고 Filebeat 컨테이너를 정의합니다.

• jaeger: SPAN_STORAGE_TYPE을 elasticsearch로 설정하여 트레이스 데이터를 Elasticsearch에 보냅니다.
• filebeat: 애플리케이션 로그 파일을 읽어 Elasticsearch로 보내는 역할을 합니다.
• otel-collector: OpenTelemetry 데이터를 수집하고 Jaeger로 전달하는 역할을 합니다. 이 컨테이너는 모든 트레이스 데이터를 단일 지점에서 처리하는 역할을 합니다.

추가적으로 아래 설정 파일들도 추가가 필요하다

3. 애플레키에션 로깅 설정

<configuration>
    <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
        <encoder>
            <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} [%X{traceId}] [%X{spanId}] - %msg%n</pattern>
        </encoder>
    </appender>
    <root level="info">
        <appender-ref ref="CONSOLE"/>
    </root>
</configuration>

4. 최종  

이번에는 ECS 활용하여  배포서비스를 만들려고한다. ecs는 기본적으로  롤링 배포가 가능하다. 이를 활용하여 배포 파이프라인을 쉽게 만들어보고자 한다. 

일단 롤링 배포를 간략하게 설명하면 

롤링 배포는 가장 일반적인 무중단 배포 방식 중 하나이며,  기존의 오래된 버전(Old Task)을 새로운 버전(New Task)으로 하나씩 점진적으로 교체하는 방식이다. 이 과정에서 구 버전과 신 버전이 공존하며 트래픽을 처리하기 때문에, 서비스 중단 없이 배포를 완료할 수 있다.

1. AWS 설정

이전 과 마찬가지로 로드밸런서 및 그룹 설정

ECS 클러스터 및 서비스 

*클러스터 관련 주의사항  인스턴수 최소 수량 체크 및    컨테이너 포트 같은 것들은 꼭 잘 확인하고 진행하기 바란다.

3.  배포관련 설정 파일

배포관련 파일은 작업을 정의하는 task definition 과  dockerFile,  deploy.yml 이 필요하다

위관련 파일들은 그렇게 여럽지 않게 진행 가능하다.

*실전에 녹일려면 기본 클러스터 크기나 인스턴스 크기  최대 인스턴스 수등 이렇것들은 꼭 다시 확인해야할듯하다.

4.최종 이벤트 확인 결과

5. 보완 혹은 아쉬운점

프리티어 수전에서는 아쉬운 부분이 많다.  

금액적인 제한만 없다면  좀더 완성도 있게도 개인이 만들 수 있지 않을까 싶다.

이전 배포 방식에서  ALB, 오토스케일 그룹,  템플릿,  새로운 배포그룹등 을 추가하여 만들었다.

생각보다는  타겟그룹을 지정하는 부분에서 헷갈리는 부분이 많아 AllowTraffic 이 거의 무한 로딩이 되듯 멈추지 않아 고생을 했다. 

1. 기존 배포 방식의 한계

처음에는 단일 EC2 인스턴스에 CodeDeploy를 붙여 배포하는 방식이었다.
하지만 이 방식에는 다음과 같은 한계가 있다.

• 인스턴스 하나에 문제가 생기면 서비스 전체가 중단될 위험
• 트래픽 증가에 대응할 수 없음
• 무중단 배포(Blue/Green)가 사실상 불가능

2. 개선된 아키텍처

이를 보완하기 위해 아래와 같은 구성을 적용했습니다.

• ALB (Application Load Balancer)
  트래픽을 여러 EC2 인스턴스로 분산하며, 블루/그린 전환 시 핵심 역할을 담당.
• 오토스케일 그룹 (ASG)
  Auto Scaling 그룹을 사용해 인스턴스 개수를 자동으로 조정.
  Blue 환경과 Green 환경을 별도로 관리하여 배포 중에도 서비스가 끊기지 않게함.
• 시작 템플릿 (Launch Template)
  EC2 인스턴스의 설정(AMI, 보안 그룹, 유저 데이터 등)을 표준화해 언제든 동일한 환경의 인스턴스를 생성할 수 있다.
• CodeDeploy 배포 그룹
  블루/그린 배포 전략을 적용해, 기존 인스턴스에서 새 인스턴스로 트래픽을 안전하게 전환.

3. 어려웠던 부분

• 타겟그룹 분배? 설정이 까다로웠다.  어느 부분에서는 하나의 타겟을 설정하고 배포 이후 CD를 통해 자동으로 넘겨주는 부분이라던지 혹은 2개의 그룹 모두 지정한다던지 좀 헷갈리는 부분이 꽤 있었다.
• 특히 Allow Traffic  이벤트에서 거의 10분이상 로딩이 도는 부분을 한참을 봐도 권한이나 보안그룹상으로 문제가 없는데 나와서 애먹었다. 

나의 경우는  권한 문제 보다는 ALB 그룹이 하나 빠져 있어서  생긴 문제였다.

4. 보완하고 싶은점

프리티어로 진행하는 부분들은 실제 서버 와 동일 환경 구성이 어렵다 보니 이런 부분은 항상 아쉬움이 남는다. 비용이 비용인 만큼 .. 

5.최종 배포 완료 결과물 

이후에는 ECS를 빠르게 구축하고 배포를 만들어 볼 예정 ECS 사용할때는  jenkins 를 쓸려고 한다.

CI/CD 파이프라인의 필요성

오늘날의 소프트웨어 개발에서 CI/CD(지속적 통합/지속적 배포)는 선택이 아닌 필수입니다. CI/CD를 통해 개발자는 코드를 자주, 그리고 안전하게 배포할 수 있으며, 버그를 신속하게 발견하고 수정할 수 있다. 수동으로 모든 과정을 처리하는 대신, 자동화된 파이프라인을 구축하여 생산성을 극대화하는 것이 핵심이다.

이번 글에서는 GitHub Actions를 CI 도구로, AWS CodeDeploy를 CD 도구로 활용하여 확장 가능한 CI/CD 파이프라인을 구축하는 방법을 단계별로 알아보겠다

현재 버전은  블루그린 버전이 아닌  온프레미스 방식 으로 구성하였고   이후 작성할 부분에서 변경되는 부분을 추가 하여 작성할 예정이다

아래는 구조 예시 그림이다.

크게 2가지 부분으로 보면 될것 같다. 실제 배포될 프로젝트에 필수 스크립트 및  배포 명세서를 작성하고  배포될 aws ec2 , code deploy 등 설정.

1. github 올라갈 배포 샘플 프로젝트 구성 및  필수 배포 파일 작성

dockFile  - docker 를 사용하기 위해 작성 필수

deploy.yml - 배포 명세 파일 

appsepc.yml  -  codeDeploy 사용시  필요한 명세 파일 

2. ec2  및   code Deploy 설정(CI/CD 환경 구성)

ec2 안에  실제  배포에 필요한 툴을 설치(ex) java, dockr 등)

ec2 IAM 롤 추가 필요(deploy 혹은 s3 접근을 위한)

code delpoy  애플리케이션 및   배포그룹 추가 및 설정(설정은 배포 방식에 따라 다르다) 

필수적인 부분을 잘 확인하여 배포 까지 이루어질 수 있도록 잘 작성해보자.