kubernetes

CKA 합격 후기 2025년 6월, 올해 따기로 결심했던 자격증 중 하나인 CKA에 합격했다. 개정된 시험 포맷 이후 치른 시험이었고, DevOps, MSA 아키텍처, 인프라 자동화에 깊은 관심을 가져오던 나로서는 하나의 마일스톤이 되었다. 이 글에서는 내가 CKA에 합격하기까지 어떤 전략과 학습 경로를 거쳤는지, 어떤 부분에서 시간을 쏟았는지, 그리고 실전 시험에서 어떤 식으로 접근했는지를 공유하려한다. 왜 CKA인가? 나는 온프레미스 환경(Proxmox)에서 을 이용해 직접 Kubernetes 클러스터를 구축한 경험이 있다. 여기에 MetalLB, Calico CNI, Ingress, Istio, Helm 등을 직접 적용해보면서, Kubernetes는 나에게 단순한 관심사를 넘어 직접 다루고 싶은 도구가 되었다. 나는 백엔드 개발자이지만, 나 스스로를 단순히 "백엔드 개발자"로만 규정하고 싶지 않았다. 프론트엔드부터 인프라, 운영까지 전반적인 흐름을 이해하고 다룰 수 있는

Chap 17. Workflow 관리 Argo workflow 쿠버네티스 core API에는 일회성 배치 작업을 수행하는 Job 리소스가 존재한다. 간단한 retry정책이나 parallel 실행이 가능하지만 작업간 종속성 부여, 조건부 실행, 에러 핸들링 등 고급 워크플로우 관리 기능은 부재한다. 이를 해결하고자 Argo Project에서 Argo workflow를 개발했다. Argo workflow는 쿠버네티스 워크플로우 엔진으로 CNCF의 incubating 프로젝트로 등록되어 있다. 사용자가 원하는 Workflow를 직접 구성할 수 있으며 작업간 종속성을 만들어 순차적으로 실행할 수 있다. 또한 병렬실행이나 에러 핸들링 등과 같은 고급 워크플로우 관리 기능과 사용자를 위한 웹 UI도 제공한다. 사용자는 쿠버네티스 내장 리소스처럼 워크플로우를 생성, 삭제 및 관리할 수 있다. 동작 방법 Argo workflow도 다른 Operator와 마찬가지로 사용자 정의 리소스에 따라 사용자

Chap 16. 사용자 정의 리소스 사용자 정의 리소스란? Custom Resource 사용자 정의 리소스는 쿠버네티스 API를 사용자가 원하는대로 확장한 리소스를 말한다. 예를 들어, 쿠버네티스 코어 API에 Pod라는 리소스가 있지만 사용자가 원하는 특별한 기능을 더한 MyPod라는 리소스를 새롭게 정의할 수 있다. 쿠버네티스에는 사용자가 쉽게 API를 확장할 수 있도록 CustomResourceDefinition(CRD)라는 리소스를 제공한다. CRD는 바로 새로운 리소스를 정의하는 리소스이다. - kind: CustomResourceDefinition — 이 리소스가 CRD임을 나타냄. 쿠버네티스에서 새로운 리소스 타입을 정의할 때 사용함. - name: mypods.crd.example.com — CRD의 전체 이름. . 형식을 따르며, 이 이름으로 API 서버에 등록됨. - group: crd.example.com — 해당 CRD가 속한 API 그룹. 커스텀 리소스는 코어

Chap 14. 로킹과 모니터링 쿠버네티스는 기본적으로 내장하고 있는 로깅 및 모니터링 시스템이 없다. 대신 그 기능을 Cloud Native 생태계에 맡겼다. 이번 장에서는 로킹은 EFK 스택을 이용하여, 모니터링은 Prometheus, Grafana를 이용하여 시스템을 구축해보자. 로깅 시스템 구축 클러스터 레벨 로깅의 장점 kubectl logs 명령어를 사용하면 컨테이너의 로그를 바로 확인할 수 있다. 그렇다면 왜 따로 클러스터 레벨의 로깅 시스템이 필요할까? 1. 로그 히스토리 저장 pod가 실행 중인 경우에는 kubectl logs 를 통해 로그 메시지를 확인할 수 있지만 Pod가 죽게 되거나 1회성 배치 작업인 경우, Pod가 사라지게 되어 로그 기록도 같이 삭제된다. 클러스터 레벨의 로깅 시스템을 따로 구축하여 로그 기록을 저장하면 언제든지 과거의 로그 기록들을 확인할 수 있다. 2. 시스템 컴포넌트 로그 통합 쿠버네티스에는 컨테이너뿐만 아니라

Chap 13. 접근 제어 쿠버네티스에서는 사용자의 인증/인가를 통해 아래 3단계를 통과해야 시스템에 접근할 수 있다.. 1. Authentication(인증): 접속한 사람의 신분을 인증하는 단계(누가 접근하는가). 2. Authorization(인가): 어떤 권한을 가지고 어떤 자원에 어떤 행동을 할 수 있는지 확인하는 단계. 3. Admission Control: 요청한 내용이 적절한지 확인하는 단계이다 - LimitRange, ResourceQuota 기능이 Admission Control을 통해 Pod 요청이 적절한지 확인한 예시이다. 사용자 인증 쿠버네티스에는 크게 5가지 사용자 인증 방식이 존재한다. - HTTP Authentication: 토큰, 베이직 인증 사용 - X.509 Certificate: 인증서 기반 사용자 인증 - OpenID Connect: OAuth 기반 외부 인증 - Webhook 인증: 외부 서버에 인증 위임 - Proxy 인증: 프록시 서버

Chap 12. 클러스터 관리 리소스 관리 앞서, Pod의 resource property를 통해 리소스를 관리하는 방법에 대해 알아보았다. 이번에는 LimitRange, ResourceQuota와 비교하며 차이점을 알아보자. 쿠버네티스 사용자를 크게 일반 사용자(developer)와 관리자(admin)으로 나누어 생각하면, 일반 사용자는 자신이 개발한 어플리케이션을 쿠버네티스 플랫폼 위에 실행하는 사용자이다. 관리자는 쿠버네티스 클러스터 자체를 관리하고 필요한 물리 리소스(노드, 디스크, 네트워크 등)를 제공하는 총 책임자 이다. 이 두 역할을 한 사람이 다 맡을 수도 있지만, 서로 다른 사람이 맡을 수도 있다. 이때, 클러스터 관리자가 일반 사용자에게 리소스 사용량을 제한하기 위해 사용하는 것이 LimitRange와 ResourceQuota리소스 이다. LimitRange LimitRange의 기능은 2가지이다. - 일반 사용자가 리소스 사용량 정의를 생략하더라도 자동으로 Pod

Chap 11. 고급 스케줄링 고가용성 확보 - Pod 레벨 ReplicaSet, Deployment 리소스의 replica property를 이용하여 서비스의 가용성을 높이는 방법에 대해 알아보았다. 이런 방법은 일정 범위 안의 트래픽에 대해서는 서비스 가용성이 유지되지만 처리량 범위를 넘어서는 트래픽에 대해서는 한계를 가진다. replica 개수가 정적으로 고정되어 있기 때문이다. 이러한 문제를 해결하고자 쿠버네티스에서는 Pod의 리소스 사용량에 따라 자동으로 확장하는 HorizontalPodAutoScaler(HPA)라는 리소스를 제공한다. HPA는 이름에서도 짐작할 수 있듯, Pod의 개수를 수평적으로 자동 확장한다. HPA는 metrics-server라는 컴포넌트를 사용한다. metrics-server는 Pod의 리소스 사용량을 수집하는 서버이다. 이 서버를 통해 Pod의 작업량을 모니터링하다가 사용자가 지정한 일정 수준의 임계값을 넘으면 replica 개수를 동적으로 조

Chap 10. 스토리지 쿠버네티스에서는 단순히 호스트 서버의 볼륨을 연결하는 것 외에 다양한 형태로 데이터를 저장 및 참조하는 방법들을 제공한다. 이 장에서는 다음과 같은 리소스를 살펴본다: - PersistentVolume - PersistentVolumeClaim - StorageClass PersistentVolume PV는 데이터 저장소를 추상화시킨 리소스이다. 쿠버네티스 클러스터 관리자가 데이터 저장소를 사용하기 위해 미리 마련한 저장 자원을 나타낸다. PV에는 구체적인 저장소 정보가 담겨있는데, 예를 들면: - AWS 플랫폼: EBS(Elastic Block Storage) 정보 - GCP 플랫폼: PersistentDisk 정보 - 로컬 호스트: 로컬 호스트의 볼륨 path 정보 이처럼 다양한 환경에서 다양한 저장소 타입을 제공하기 위해 쿠버네티스에서는 PersistentVolume(PV)라는 추상화된 리소스를 사용하고 각 환경에 따라 그에 맞는 타입을 선택한다.

Chap 9. Ingress 리소스 Ingress란? Ingress는 HTTP, HTTPS 등 네트워크 Layer 7에 대한 설정을 담당하는 리소스이다. Ingress의 가장 기본적인 역할은 외부 HTTP 호출에 대한 트래픽을 처리한다. 이를테면, 부하 분산, TLS 종료, 도메인 기반 라우팅 기능 등을 제공한다. Ingress는 쿠버네티스 내부 서비스에 외부 접근 가능한 URL을 부여함으로써 일반 사용자들이 쉽게 접근할 수 있는 통로를 제공한다. Ingress에는 그에 맞는 Ingress Controller가 존재하며, Ingress Controller는 Ingress에 정의된 트래픽 라우팅 규칙을 보고 라우팅을 수행한다. Ingress (출처: https://medium.com/devops-mojo) Ingress Controller란? Ingress 리소스 자체로는 어떠한 프로그램이 작동하는 코드가 아니라 트래픽 처리에 대한 정보를 담고 있는 정의(또는 규칙)에 가깝다. 실제로

Chap 8. Helm 패키지 매니저 Helm이란? helm은 쿠버네티스 패키지 매니저이다. , , 툴과 비슷하다고 생각하면 된다. helm 차트의 구조는 크게 values.yaml과 templates/ 디렉터리로 구성된다. - : 사용자가 원하는 값들을 설정하는 파일 - : 설치할 리소스 파일들이 존재하는 디렉터리로, 해당 디렉터리 안에는 , 등과 같은 쿠버네티스 리소스가 Yaml 파일 형태로 들어있다. 각 파일들의 설정값은 비워져있고(placehoolder) values.yaml의 설정값들로 채워진다. 패키지가 설치될 시점에 파일의 설정값들을 이용하여 templates 디렉터리에 들어있는 Yaml 파일의 구멍난 부분(placeholder)을 채운다. 파일에는 - 자주 바뀌거나 사용자마다 달라지는 설정값들을 입력하는 용도로 사용하고 디렉터리는 패키지의 뼈대를 이룬다. helm chart helm을 잘 활용하면 다른 사람이 만든 애플리케이션도 손쉽게 나의 쿠버네티스 클러스터로 가

Chap 7. 쿠버네티스 컨트롤러 컨트롤러란? 쿠버네티스에는 컨트롤러라는 컴포넌트가 있다. 컨트롤러는 특정 리소스를 지속적으로 관찰하며 리소스의 생며웆기에 따라 미리 정해진 작업을 수행하는 주체를 말한다. 이에 대해 정확히 알려면 쿠버네티스의 와 에 대해 살펴봐야 한다. 쿠버네티스 클러스터는 현재 클러스터 상태를 관찰하며 사용자가 원하는 상태와 동일해지도록 정해진 작업을 수행한다. 쿠버네티스 컨트롤러는 라는 루프를 지속적으로 돌면서 특정 리소스에 대해 관찰하고, 사용자의 요청에 따라 를 업데이트 한다. 컨트롤러는 그것을 인지하고 가 와 동일해지도록 조정한다. ReplicaSet ReplicaSet 리소스는 Pod을 복제한다. Pod을 복제하면 1개의 Pod에 문제가 생기더라도 다른 Pod을 이용하여 가용성을 보장할 수 있다. - replicas: 복제한 Pod의 개수를 정의한다. - selector.matchLabels: Service와 마찬가지로 복제 개수를 유지할 Pod을 선

Chap 6. 쿠버네티스 네트워킹 Service 쿠버네티스에는 Pod 자체에도 IP가 부여된다. curl 명령을 통해 Pod IP로 호출을 하면 정상적으로 결과를 반환한다. 그렇다면 왜 Service라는 리소스가 필요한걸까? 위와 같이 Pod의 IP로 바로 연결이 가능한데도 말이다. 불안정한 Pod vs. 안정적인 Service 쿠버네티스에서는 Pod 리소스를 불안정한 자원으로 여긴다. Pod는 필요한 경우 쉽게 생성하였다가 사용이 끝나면 쉽게 삭제될 수 있는 만큼, Pod에 할당된 IP는 불안정한 엔드포인트로 간주된다. 이 때문에, 사용자가 Pod의 엔드포인트를 통해 애플리케이션과 소통을 시도한다면, Pod가 변경되거나 내려가거나 새로 생성될때마다 사용자는 바뀐 IP를 추적해야만 할 것이다. 이 문제를 해결하고자 Pod의 생명주기와 관계없이 안정적인 엔드포인트를 제공하는 Service라는 리소스가 등장하게 되었다. Service는 Pod의 앞단에 위치하며 Service로 들어오는

Liveness Probe vs. Readiness Probe 쿠버네티스에서 Liveness Probe와 Readiness Probe는 컨테이너의 상태를 체크하여 트래픽 라우팅 및 자동 복구에 중요한 역할을 한다. 이 글에서는 두 개의 프로브(probe)가 어떤 차이가 있는지, 언제 사용해야 하는지에 대해 살펴본다. Liveness Probe (생존 여부 확인) 역할: Liveness Probe는 컨테이너가 살아 있는지 확인하는 역할을 한다. 만약 컨테이너가 정상적인 상태를 유지하지 못하면, 쿠버네티스가 해당 컨테이너를 자동으로 재시작한다. 예제: HTTP 기반 Liveness Probe 엔드포인트를 10초마다 호출하여 컨테이너의 생존 여부를 체크. 응답이 없거나 500 에러를 반환하면 Pod를 강제 재시작. 사용 사례 - 애플리케이션이 무한 루프에 빠져 응답을 하지 않는 경우 - 애플리케이션이 메모리 부족(OutOfMemoryError) 등으로 내부적으로 멈춘

Chap 5. Pod 살펴보기 Pod 소개 Pod는 쿠버네티스의 최소 실행 단위이다. 가상머신의 Instance나 도커의 Container와 같은 포지션에 위치해 있다. Pod 특징 출처: https://medium.com/techbeatly/kubernetes-networking-fundamentals-d30baf8a28c8 Pod는 다음과 같은 특징들을 갖는다. 1개 이상의 컨테이너 실행 Pod은 1개 이상의 컨테이너를 가질 수 있다. 보통은 1개 Pod 내에 한 개 컨테이너를 실행하지만 상황에 따라서 2개, 많게는 3개까지 컨테이너를 실행한다. 💡 istio같은 서비스 메시를 사용하면, 로그 수집 등의 목적을 위해 하나의 pod안에 사이드카 패턴으로 프록시컨테이너를 넣는 경우를 볼 수 있다. 동일 노드에 할당 Pod내에 실행되는 컨테이너들은 반드시 동일한 노드에 할당되며 동일한 생명주기를 갖는다. Pod 삭제시, Pod 내의 모든 컨테이너가 전부 같이 삭제된다. 고유

Chap 4. 쿠버네티스 첫만남 기본 명령 파드 실행 kubectl run \ --image \ 위 명령어로 새로운 컨테이너(pod)을 실행시킬 수 있다. 파드 확인 kubectl get pod 위 명령어로 배포된 컨테이너(pod)을 확인할 수 있다. - nginx 파드가 배포된 모습이다. get 명령의 세번째 컬럼 STATUS는 현재 pod의 상태 정보를 나타낸다. pod이 가질 수 있는 상태는 다음과 같다. 상태 정보 상세조회 특정 Pod의 상태 정보를 더 자세히 보고 싶다면 -o yaml 옵션을 추가하면 된다 위와 같이 PodIP, nodeName등 다양한 상세 정보를 확인 가능하다. 각 Pod 요약정보 추가 호출 각 Pod의 IP등 정보를 바로 확인하려면 -o wide 옵션을 사용할 수 있다. - 내부 IP 로 가 할당된것을 확인 가능하다. 💡 k8s 내부 리소스들의 IP는 따로 DHCP와 같은 프로토콜로 할당되는 것이 아닌 CNI 플러그인을 통해 할당된다. 파드 상세정보