JH-Labs

controlplane을 구성하는 Pod IP 확인 현재 클러스터의 Pod CIDR은 10.244.0.0/16로 설정되어 있으며 호스트 CIDR은 172.31.50.113/20로 설정되어 있는 상태이다. 하지만 controlplane을 구성하는 Pod IP를 확인한 결과 kube api server를 비롯한 각종 Pod는 CNI 망에 속하지 않는 것을 볼 수 있다. cf. Pod CIDR 확인하기 k describe po -n kube-system | grep -i ip API server, kube-proxy와 같은 Master Node의 컴포넌트들은 CNI 망에 속하지 않고 호스트 네트워크 영역을 따른다.(모든 Master Node 컴포넌트가 그러한 것은 아님) 즉, 컨테이너(Pod)로 띄워지더라도 ..

Horizontal Pod Autoscaler(HPA) 및 Vertical Pod Autoscaler(VPA) [Horizontal Pod Autoscaler (HPA)] HPA는 Kubernetes에서 가장 일반적으로 사용되는 오토 스케일링 기술로 애플리케이션의 수평적인 replicas 수를 동적으로 조정하여 애플리케이션의 부하에 따라 자동으로 조정하는 기능을 제공한다. HPA는 CPU 사용률, 메모리 사용률 또는 사용자 정의 지표를 기반으로 Pod의 replicas 수를 조정한다. [Vertical Pod Autoscaler (VPA)] HPA는 Pod의 replicas 수를 조정하여 가용 자원의 사용을 최적화하지만, VPA는 개별 Pod의 resources, request을 조정하여 수직 스케일링을..

Kustomize kustomize는 쿠버네티스에서 오브젝트들의 Manifest들을 사용자가 원하는 방식대로 변경해서 쿠버네티스 환경에 배포할 수 있도록 하기 위한 목적으로 사용되는 플러그인이다. 과거에는 바이너리 파일을 다운로드해서 kubectl과 연동했다고 한다. 하지만 쿠버네티스 1.13 버전부터는 kubectl 커맨드의 기본 플러그인으로 자리 잡았다. kustomize가 사용되는 대표적인 예시는 CI/CD 파이프라인 관리이다. (예를 들어, 애플리케이션의 Manifest 파일을 수정하여 GipOps 기반의 변경 사항을 발생시킬 때) 대표적인 기능 4가지 1) 리소스 집합을 구성하고 사용자 정의 - Manifest 파일들을 그룹으로 관리하고 한번에 실행, 삭제 등의 관리 기능 1) 원격에서 kust..

CronJob - Deployment와 ReplicaSet의 관계처럼 CronJob에도 Job의 기능이 포함되어 있다. - Deployment가 ReplicaSet을 컨트롤하여 Rolling Update를 지원했던 것처럼 CronJob은 Job을 컨트롤해서 원하는 특정 시간에 Job이 실행될 수 있도록 작업 '예약' 기능을 지원한다. - 예를 들어, 이메일을 주기적으로 보내는 작업, 로그파일을 주기적으로 정리하는 작업, 데이터 백업 작업, 가비지 데이터를 주기적으로 삭제해주는 작업 등 특정 주기를 가지고 반복해서 실행해주는 작업에 대해 CronJob으로 정의할 수 있다. - 애플리케이션이 비정상적으로 동작하여 Pod를 재시작하거나 컨테이너를 재시작하는 것은 Job 컨트롤러 고유의 기능이며 CronJob은..

Job Controller 쿠버네티스의 가장 기본적인 특징은 Pod를 항상 Running 중인 상태로 보장해준다는 것이다. 하지만 배치 처리처럼 특정 시점에만 Pod가 필요하다면 Job 컨트롤러를 사용하는 것이 해답이 될 수 있다. Job Controller에 의해서 Pod를 실행시키면 해당 Job에 대한 결과(정상인지에 대한 여부)를 점검해서 비정상으로 종료되었을 경우에는 다시 재시작해준다는 특징이 있다. 실습 예시 1) restartPolicy: Never - job-exam.yaml 파일 apiVersion: batch/v1 kind: Job metadata: name: centos-job spec: # completions: 5 # parallelism: 2 # activeDeadlineSecon..

StatefulSet StatefulSet은 상태(Pod 이름, Pod 볼륨)를 보존해주는 컨트롤러이다. Pod를 생성할 때 NAME 뒤에 추가되는 5자리의 문자는 랜덤으로 생성된 Hash 값이다. 컨트롤러에 의해 만들어진 모든 Pod는 이와 같이 랜덤 해시 값이 붙은 형태로 Pod 이름이 형성된다. 특정 Pod를 지우고 다시 실행되는 Pod의 이름을 보면 이전과 달라진 해시값을 가진다. 즉, Pod의 이름이 보장되지 않는다는 것을 의미한다. 이전까지 배운 컨트롤러는 'Pod의 개수를 보장'해주었지만 Pod의 이름을 보장해주지는 않았다. StatefulSet은 다른 컨트롤러와 다르게 아래 두 가지를 보장해주는 컨트롤러이다. 1) Pod 이름 2) Pod 저장소 (스토리지, 볼륨) Pod 이름을 어떻게 보..

이전 포스팅에서 다룬 컨트롤러 - ReplicationController: 컨트롤러의 가장 근본적인 역할을 하는 컨트롤러로 Pod의 개수를 보장 - ReplicaSet: 풍부한 label을 지원하여 다양한 조건에 해당하는 Pod 개수 보장 - Deployment: ReplicaSet을 컨트롤하며 Rolling Update를 지원 -> 결국 세 개의 컨트롤러는 모두 'Pod의 개수를 보장'하는 것이 주요 역할이었던 컨트롤러였다. DaemonSet도 Pod의 개수를 보장하지만 다른 컨트롤러와 비교해보면 약간 성격이 다르다. DaemonSet - 이전에 다룬 다른 컨트롤러와 달리 DaemonSet은 노드 당 1개씩의 Pod를 보장하는 컨트롤러이다. - 운영 중에 노드가 추가되면 추가된 노드 개수만큼 Pod를 ..

Deployment - Controller인 ReplicaSet을 제어해주는 부모 역할을 한다. - Deployment는 Rolling Update를 목적으로 만들어졌다. - Deployment를 만들면 Deployment가 ReplicaSet을 만든다. 이때 Deployment는 실행시킬 Pod의 버전과 replicas를 ReplicaSet에게 전달한다. 그 후엔 ReplicaSet이 전달받은 정보를 기반으로 Pod를 생성하고 Pod 수를 보장하게 된다. - 즉, Deployment가 ReplicaSet을 컨트롤하고 ReplicaSet이 Pod를 컨트롤하는 구조이다. - 정리하자면, Deployment는 ReplicaSet Controller를 관리해서 Pod 수를 보장하고, 추가적으로 Rolling ..