쿠버네티스 69

쿠버네티스 Config 변경을 위한 Kustomize

쿠버네티스 Config 변경을 위한 Kustomize 조대협 (http://bcho.tistory.com) 쿠버네티스 환경을 운영하면, 같은 설정을 다른 클러스터에 배포해야 하는 시나리오가 있다. 예를 들어서 애플리케이션을 개발/테스트/운영 (dev/stage/production)환경에 배포해야 하는데, 이 경우에 세부 설정이 조금씩 다를 수 있다. 이때 각 환경별로 파일을 만들면 관리가 어렵고 비효율적이기 때문에, 다른 세부 설정만 이러한 문제를 해결하기 위한 도구들이 Kubernetes 배포 도구이다. 대표적인 도구로 Kustomize, Helm, Ksonnet 예를 들어 아래 그림과 같이 deployment를 정의한 YAML 파일이 있을때 전체 설정을 수정하지 않고 replica 수만 개발/테스트/..

간단하게 알아보는 Kubernetes Operator의 개념과 Kopf 프레임웍

간단하게 알아보는 Kubernetes Operator의 개념과 Kopf 프레임웍 조대협 (http://bcho.tistory.com) 쿠버네티스에는 Deployment, Service,Pod 등 여러 predefined resource가 있다. 이런 pre-defined resource 이외에 새로운 리소스를 정의해서 등록해서 사용할 수 있는데, 이를 Controller 또는 Operator라고 한다. Controller와 Operator는 용어가 종종 혼용되어 사용되는데, 분류를 하자면 Controller는 Kubernetes에 이미 정의되어 있는 Pre-defined resource를 , Operator는 사용자가 정의한 애플리케이션 리소스를 지칭한다. Operator는 Stateless applic..

이벤트 베이스 쿠버네티스 오토스케일링 KEDA

이벤트 베이스 쿠버네티스 오토스케일링 KEDA 보통 인스턴스 수를 늘이는 오토 스케일러는 메모리나 CPU와 같은 기초적인 자원 사용양에 따라서 작동하는 경우가 많다. 그러나 이보다는 애플리케이션의 큐 길이나 메시지 큐의 길이 또는 특정 이벤트에 따라서 자원을 스케일링 하는 것이 더 논리적인데, 이렇게 하기 위해서는 커스텀 메트릭을 프로메테우스등으로 수집한후, 이 메트릭을 CA (Cluster Autoscaler)에 적용하는 방법으로 구현해야 하는데, 구현의 복잡도가 높다. KEDA 오픈 소스는 Redis나 기타 오픈소스 또는 클라우드 자원과 쉽게 통합하여, 거기서 발생하는 이벤트를 이용하여 오토 스케일링을 손쉽게 가능하게 해준다. https://keda.sh/docs/1.4/scalers/redis-li..

쿠버네티스의 HPA/VPA 오토스케일링을 위한 모니터링 아키텍처

쿠버네티스의 HPA/VPA 오토스케일링을 위한 모니터링 아키텍처 조대협 (http://bcho.tistory.com) 쿠버네티스에서 HPA/VPA는 내부 메트릭을 이용하여 오토스케일링을 판단하는데, 이를 위해서 내부 메트릭을 수집하고 서빙하기 위한 모니터링 아키텍쳐가 어떻게 구현되었는지에 대해서 알아본다. 각 노드에서 동작하는 컨테이너에 대한 리소스 정보 (CPU,메모리, 네트워크 사용량)은 cAdvisor를 통하여 수집되어 Kubelet을 통해서, 컨트롤 플레인에 전달된다. cAdvisot는 컨테이너에 대한 리소스 정보만 수집하지만, Kubelet은 컨테이너 이외의 노드나 애플리케이션에 대한 정보를 수집한다. 이렇게 Kubelet에 저장된 정보는 metric server로 전달되고, metric api..

Prometheus 를 스케일링 하기 위한 Thanos (타노스)

문제 정의 프로메테우스가 좋은 모니터링 시스템이긴 하지만 두가지 결정적인 문제점을 가지고 있다. 결정적으로 클러스터링 구조를 지원하지 않기 때문에, 확장성과 가용성 문제를 가지고 있다. 확장성 측면에서는 디스크를 증설하거는 것과 같은 하드웨어 스펙 증설로 어느정도는 해결이 가능하지만 데이타 볼륨이 늘어나고 모니터링 대상이 늘어나면 하나의 프로메테우스 인스턴스로는 감당이 어렵다. 이런 문제를 해결하는 방법으로는 Federation 이라는 방법을 사용한다. 프로메테우스 인스턴스를 여러개를 기동한 다음에, 중앙에 다른 프로메테우스로 부터 메트릭을 수집하는 다른 프로메테우스를 놓는 방식이고, 데이타 양에 대한 문제는 데이타의 해상도 (예를 들어 전면에 데이타 수집 서버가 10초 단위로 수집 했다면, 중앙 서버에..

오픈소스 모니터링 툴 - Prometheus #3 그라파나를 이용한 시각화

프로메테우스 #3. 그라파나를 이용한 시각화조대협 (http://bcho.tistory.com) 그라파나(Grafana)는 메트릭을 시각화 해주는 오픈소스 도구이다. Graphite, Prometheus, InfluxDB등 다양한 데이타베이스와 메트릭수집 시스템을 지원하고, 하나의 대쉬보드에 동시에 여러 메트릭 시스템들의 지표를 표시할 수 있고 무엇보다 설치 및 사용 방법이 쉽기 때문에 널리 사용되고 있다특히 프로메테우스를 잘 지원하고 있기 때문에, 프로메테우스의 메트릭을 그래프로 시각화 하는데도 많이 사용된다. 그라파나의 설치는 비교적 간단한 편이기 때문에 여기서는 별도로 설명하지 않는다. 설치 방법은 공식 문서 https://grafana.com/docs/grafana/latest/installati..

오픈소스 모니터링툴 - Prometheus #1 기본 개념과 구조

프로메테우스 #1 기본 개념과 구조조대협 (http://bcho.tistory.com) 프로메테우스는 오픈 소스 기반의 모니터링 시스템이다. ELK 와 같은 로깅이 아니라, 대상 시스템으로 부터 각종 모니터링 지표를 수집하여 저장하고 검색할 수 있는 시스템이다. 구조가 간단해서 운영이 쉽고, 강력한 쿼리 기능을 가지고 있으며, 그라파나(Grafana) 를 통한 시각화를 지원한다. 무엇보다 넓은 오픈 소스 생태계를 기반으로 해서, 많은 시스템을 모니터링할 수 있는 다양한 플러그인을 가지고 있는 것이 가장 큰 장점이다. 특히 이런 간편함 때문에 특히나 쿠버네티스의 메인 모니터링 시스템으로 많이 사용되면서 요즘 특히 더 주목을 받고 있다. 기본 구조프로메테우스의 기본적인 아키텍처 부터 살펴보자먼저 수집 저장 ..

오픈소스 부하테스트툴 Locust #2 - 분산 부하 테스팅 (with 쿠버네티스)

Locust 와 쿠버네티스를 이용한 분산 부하 테스트조대협 (http://bcho.tistory.com)분산 부하 테스트locust는 여러개의 worker를 이용하여, 부하를 대량으로 발생 시키는 분산 부하 테스트가 가능하다. 특히 분산 클러스터 구성 설정이 매우 간단하다는 장점을 가지고 있다. 마스터 노드의 경우에는 아래와 같이 --master 옵션을 지정하여 마스터 노드로 구동하면 되고, % locust -f {task file name} --host={target host address} --master 워커 노드의 경우에는 실행 모드를 slave로 하고, 마스터 노드의 주소만 명시해주면 된다. % locust -f {task file name} --host={target host address} ..

Kong API gateway #3 - Kong on Kubernetes

오픈소스 API 게이트웨이 Kong#3 쿠버네티스 Kong조대협 (http://bcho.tistory.com) Kong KubernetesAPI 게이트웨이가 마이크로서비스의 중요 컴포넌트이다 보니, Kong이 마이크로 서비스에 적합한 K8S (aka. 쿠버네티스)에 어떻게 적용될 수 있는지가 궁금해서 아키텍쳐 관련 설명 내용을 찾아보았다. https://konghq.com/blog/kong-kubernetes-ingress-controller/ (아래 그림은, 이 동영상에서 캡춰하여 사용하였다.) 에 보면 Kong summit에서 발표된 영상이 있는데, 정리가 매우 잘되어 있다. 기본 컨셉을 먼저 요약해보자면, Kong의 리소스들은 K8S의 리소스로 등록되어 사용되게 된다. API 게이트 웨이는 Ingr..

Kong API gateway #2 - 간단한 아키텍쳐와 API 테스트

오픈소스 API 게이트웨이 Kong#2 아키텍쳐와 간단한 테스트조대협 (http://bcho.tistory.com)Kong 아키텍쳐Kong API 서버의 배포 아키텍쳐는 다음과 같다. 출처 : stackoverflow.comKong API 게이트웨이 각각 nginx 로 되어 있고, DB 모드의 경우에는 별도의 데이타 베이스 인스턴스를 사용한다. 지원되는 데이타 베이스로는 카산드라나 postgres를 사용할 수 있다. 데이타 베이스를 사용하더라도 변경된 설정은 인스턴스에 바로 반영되지 않는다. 각 인스턴스가 설정 내용을 캐슁하기 때문인데, 캐쉬가 리프레쉬되어야 설정 내용이 반영된다. 클러스터에서 Kong API 게이트웨이 인스턴스간의 로드 밸런싱을 하기 위해서는 각 인스턴스 앞에 로드밸런서를 배치 시킨다...