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

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)라는 추상화된 리소스를 사용하고 각 환경에 따라 그에 맞는 타입을 선택한다. hostPath PV …

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

Chap 8. Helm 패키지 매니저 Helm이란? helm은 쿠버네티스 패키지 매니저이다. , , 툴과 비슷하다고 생각하면 된다. helm 차트의 구조는 크게 values.yaml과 templates/ 디렉터리로 구성된다. : 사용자가 원하는 값들을 설정하는 파일 : 설치할 리소스 파일들이 존재하는 디렉터리로, 해당 디렉터리 안에는 , 등과 같은 쿠버네티스 리소스가 Yaml 파일 형태로 들어있다. 각 파일들의 설정값은 비워져있고(placehoolder) values.yaml의 설정값들로 채워진다. 패키지가 설치될 시점에 파일의 설정값들을 이용하여 templates 디렉터리에 들어있는 Yaml 파일의 구멍난 부분(placeholder)을 채운다. 파일에는 자주 바뀌거나 사용자마다 달라지는 설정값들을 입력하는 용도로 사용하고 디렉터리는 패키지의 뼈대를 이룬다. 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 특징 Pod는 다음과 같은 특징들을 갖는다. 1개 이상의 컨테이너 실행 Pod은 1개 이상의 컨테이너를 가질 수 있다. 보통은 1개 Pod 내에 한 개 컨테이너를 실행하지만 상황에 따라서 2개, 많게는 3개까지 컨테이너를 실행한다. 💡 istio같은 서비스 메시를 사용하면, 로그 수집 등의 목적을 위해 하나의 pod안에 사이드카 패턴으로 프록시컨테이너를 넣는 경우를 볼 수 있다. 동일 노드에 할당 Pod내에 실행되는 컨테이너들은 반드시 동일한 노드에 할당되며 동일한 생명주기를 갖는다. Pod 삭제시, Pod 내의 모든 컨테이너가 전부 같이 삭제된다. 고유의 Pod IP 각 Pod는 클러스터 내에서 접근 가능한 고유의 IP를 할당받는다. 도커 컨테이너의 경우 다른 노드에 위치한 컨테이너간의 통신을 하기 위…

Chap 4. 쿠버네티스 첫만남 기본 명령 파드 실행 kubectl run —image 위 명령어로 새로운 컨테이너(pod)을 실행시킬 수 있다. 파드 확인 kubectl get pod 위 명령어로 배포된 컨테이너(pod)을 확인할 수 있다. nginx 파드가 배포된 모습이다. get 명령의 세번째 컬럼 STATUS는 현재 pod의 상태 정보를 나타낸다. pod이 가질 수 있는 상태는 다음과 같다. 상태값 설명 Pending 쿠버네티스 마스터에 생성 명령은 전달되었지만 실행되지 않은 상태(PVC 마운트 오류 등으로 발생할 수 있음) ContainerCreating 특정 노드에 스케줄링되어 컨테이너를 생성중인 단계(이미지 다운로드 등) Running Pod가 정상적으로 실행되고 있는 상태 Completed 계속 실행되고 있는 프로세스가 아닌, 한 번 실행하고 완료되는 배치작업 Pod에서 작업이 완료된 상태 Error Pod에 문제가 생겨 에러가 발생한 …

Chap 2. 쿠버네티스 소개 쿠버네티스란? 💡 이전에 나루었던 내용과 겹치는 부분이 있지만, 스터디 목적으로 복습할겸 쿠버네티스에 대한 대략적인 내용을 다시 기술해봅니다. 쿠버네티스는 컨테이너 오케스트레이션 도구로, 여러 컨테이너를 체계적으로 관리하는 도구 중 하나다. 쿠버네티스를 사용하면, 컨테이너의 배포, 확장 및 스케줄링을 자동화할 수 있다. 쿠버네티스의 역사 쿠버네티스(Kubernetes)는 그리스어로 “키잡이(helmsman, κυβερνήτης)” 를 의미하며, 조 베다(Joe Beda), 브랜든 번스(Brendan Burns), 크레이그 맥루키(Craig McLuckie) 가 Google에서 내부 프로젝트인 Borg를 기반으로 설계한 컨테이너 오케스트레이션 시스템이다. 이후 Cloud Native Computing Foundation(CNCF) 에서 오픈소스로 관리되며 현재까지 발전을 이어가고 있다. 컨테이너 오케스트레이션이란? 다수의 서버 위에서 컨테이너의 전반적…

쿠버네티스 온프레미스에 설치하기(with Proxmox) 쿠버네티스 클러스터를 직접 구성하는 도구 kubeadm 쿠버네티스에서 공식 제공하는 클러스터 생성/관리 도구 kubespray 쿠버네티스 클러스터를 배포하는 오픈소스 프로젝트 다양한 형식으로 쿠버네티스 클러스터 구성가능 온프레미스에서 상용 서비스 클러스터 운영시 유용 다양한 CNI 제공 CNI(Container Network Interface) Container간 통신을 지원하는 VxLAN, Pod Network라고도 부름 다양한 종류의 플러그인이 존재 flannel, calico, weavenet 등이 있다. 본 포스팅에서는 weavenet 샤용 💡CNI란? CNCF(Cloud Native Computing Foundation)의 프로젝트 중 하나인 는 컨테이너 간의 네트워킹을 제어할 수 있는 플러그인을 만들기 위한 표준이다. 다양한 형태의 컨테이너 런타임과 오케스트레이터 사이의 네트워크 계층을 구현하는 방식이 다양하게 …

쿠버네티스 쿠버네티스란? 컨테이너는 애플리케이션을 포장하고 실행하는 좋은 방법이다. 프로덕션 환경에서는 애플리케이션을 실행하는 컨테이너를 관리하고 가동 중지 시간이 없는지 확인해야 한다. 예를 들어 컨테이너가 다운되면 다른 컨테이너를 다시 시작해야 한다. 이 문제를 시스템에 의해 처리한다면 더 쉽지 않을까? 그것이 쿠버네티스가 필요한 이유이다! 쿠버네티스는 분산 시스템을 탄력적으로 실행하기 위한 프레임 워크를 제공한다. 애플리케이션의 확장과 장애 조치를 처리하고, 배포 패턴 등을 제공한다. 예를 들어, 쿠버네티스는 시스템의 카나리아 배포를 쉽게 관리할 수 있다. 쿠버네티스는 다음을 제공한다. 서비스 디스커버리와 로드 밸런싱: 쿠버네티스는 DNS 이름을 사용하거나 자체 IP 주소를 사용하여 컨테이너를 노출할 수 있다. 컨테이너에 대한 트래픽이 많으면, 쿠버네티스는 네트워크 트래픽을 로드밸런싱하고 배포하여 배포가 안정적으로 이루어질 수 있다. 스토리지 오케스트레이션: 쿠버네티스를 사…