블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 
 



프로메테우스 #3. 그라파나를 이용한 시각화

조대협 (http://bcho.tistory.com)


그라파나(Grafana)는 메트릭을 시각화 해주는 오픈소스 도구이다. Graphite, Prometheus, InfluxDB등 다양한 데이타베이스와 메트릭수집 시스템을 지원하고, 하나의 대쉬보드에 동시에 여러 메트릭 시스템들의 지표를 표시할 수 있고 무엇보다 설치 및 사용 방법이 쉽기 때문에 널리 사용되고 있다

특히 프로메테우스를 잘 지원하고 있기 때문에, 프로메테우스의 메트릭을 그래프로 시각화 하는데도 많이 사용된다. 

그라파나의 설치는 비교적 간단한 편이기 때문에 여기서는 별도로 설명하지 않는다. 설치 방법은 공식 문서 https://grafana.com/docs/grafana/latest/installation/debian/ 를 참고하기 바란다. 

이 문서에서 사용한 테스트 환경은 katakoda.com에서 그라파나 튜토리얼 환경을 이용하였다. https://www.katacoda.com/courses/prometheus/creating-dashboards-with-grafana


앞의 문서 (https://bcho.tistory.com/1373) 에 따라서 프로메테우스를 설치하였으면, 그라파나를 설치한다. 

다음 그라파나 웹 관리 화면으로 접속을 하고 로그인을 하면 아래와 같은 화면을 볼 수 있다. 



이 화면에서 Add Data source를 선택해서 프로메테우스 서버를 새로운 데이타 소스로 등록할것이다.

아래 메뉴에서 데이타 소스의 이름을 “Prometheus”로 설정하고, 타입을 Prometheus로 선택한다.

다음 Http Setting 부분의 Url 부분에, Prometheus 서버의 주소를 적어넣는다. 이 예제에서는 로컬에 프로메테우스를 기동 시켰기 때문에, http://localhost:9090 을 입력하면 된다. 



이제 프로메테우스 서버와 그라파나가 연결되었다. 

이제 그래프를 그려볼 예정인데, 초기 화면으로 돌아가서 “Create your first dash board” 메뉴를 선택한다. 다음 New Dash 보드 메뉴를 선택하여 비어 있는 대쉬 보드를 하나 만든다. 



다음에 그래프를 하나 선택하면 아래와 같이 빈 그래프가 나오는데, 이 그래프를 프로메테우스의 메트릭과 연결할것이다. 




그래프에서 상단의 “Panel Title” 를 누르면 아래 그림과 같이 메뉴가 나오는데, 여기서 “Edit” 메뉴를 선택한다.  그러면 아래와 같이 설정을 할 수 있는 화면이 나오는데, 여기서 “Metric” 메뉴를 선택한다.




Metric 메뉴에서는 시각화 하고 싶은 프로메테우스의 필드를 선택하면 되는데, PrometheusQL을 사용해서 정의할 수 도 있다. 여기서는 간단하게 node의 CPU정보를 시각화 하기 위해서 node_cpu 를 선택하였다. 그러면 아래와 같이 node_cpu 메트릭에 대한 정보를 그래프로 그려주는 것을 확인할 수 있다. 



그라파나에서는 널리 사용되는 시스템에 대한 대쉬보드를 템플릿 형태로 만들어서 사용자들이 서로 공유할 수 있도록 하는데, 템플릿은  https://grafana.com/dashboards 에 가면 찾아볼 수 있다.

여기서는 프로메테우스 node_exporter에 의해서 제공되는 메트릭을 모니터링할 수 있는 대쉬보드를 import 해서 사용해보자. 


초기화면에서 대쉬보드 생성 메뉴로 들어 간 후에, 아래 그림에서 import dashboard 메뉴를 선택하자


그러면 아래와 같이 import 화면이 나오는데, 대쉬 보드 설정을 json 파일로 업로드 할 수 도 있지만, 그라파나 대쉬보드 웹사이트에 있는 경우에는 아래 처럼 URL이나 dashboard id를 넣으면 된다.

아래 그림처럼 https://grafana.com/dashboards/22 를 필드에 입력한다.



로딩된 대쉬 보드를 보면 다음과 같다.





지금까지 프로메테우스에 대한 소개와 내부 구조, 그리고 간단한 사용법 및 시각화 방법에 대해서 알아보았다. 이 정도면 기본적인 모니터링 시스템 구성에는 문제가 없지만, 프로메테우스는 앞선 글에서도 언급 하였듯이 싱글 서버가 기동되는 구조이기 때문에, 확장성과 장애에 취약한 단점을 가지고 있는데, 다음글에서는 이 문제를 어떻게 해결할 수 있는지에 대해서 알아보도록 하겠다.

본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

프로메테우스

#2 Hello Prometheus 조대협 (http://bcho.tistory.com)

프로메테우스에 대해서, 이해하기 위해서 간단한 테스트를 진행하는데, 테스트는 http://www.katacoda.com/ 를 이용하였다. 웹상에서 쿠버네티스, 프로메테우스,텐서플로우등 다양한 기술을 별도의 설정이나 서버없이 해볼 수 있기 때문에, 기술에 대한 개념을 잡는데 매우 유용하다. 

설정 파일 정의 

프로메테우스의 설정은 prometheus.yml 파일에 정의 한다. 아래는 간단한 예제이다. 


global:

  scrape_interval:     15s

  evaluation_interval: 15s


scrape_configs:

  - job_name: 'prometheus'


    static_configs:

      - targets: ['127.0.0.1:9090', '127.0.0.1:9100']

        labels:

          group: 'prometheus'


scrap_interval은 타겟 시스템으로 부터 메트릭을 읽어오는 주기이다. 읽어온 메트릭을 기반으로 룰에 따라서 alert을 보낼 수 있는데, alert을 보낼지 말지 메트릭을 보고 판단하는 주기가 evaluation_interval 이다. 


scrap_configs 부분이 데이타 수집 대상과 방법을 정의하는 부분인데, 먼저 job에 대한 개념을 이해해야 한다. job은 대상 그룹에서 메트릭을 수집해오는 내용을 정의하는데, job은 하나의 시스템이 아니라 특성이 같은 하나의 시스템 그룹정도의 개념으로 생각하면 된다. 예를 들어 오토 스케일링 그룹으로 묶여 있는 웹서버 1,2,3을 수집한다고 했을때, 이 3개의 메트릭을 수집하는 것이 하나의 job으로 정의되고, 각각의 서버를 instance라고 한다. 


위에서는 127.0.0.1:9090, 127.0.0.1:9100 에서 메트릭을 수집하도록 job을 하나 정의 했는데, prometheus 가 기동되고 있는 서버로 부터 메트릭을 읽어오도록 설정하였다. 앞에는 프로메테우스 시스템 자체의 메트릭이고, 두번째는 프로메테우스가 기동되고 있는 VM(또는 서버,또는 도커)의 시스템 메트릭을 수집하도록 정의하였다.

프로메테우스 서버와 node exporter 기동

설정의 끝났으면 프로메테우스 서버를 기동하다. 설치에는 여러가지 방법이 있지만, 간단하게 도커 이미지를 이용하여 기동하였다. 

docker run -d --net=host \

     -v /root/prometheus.yml:/etc/prometheus/prometheus.yml \

     --name prometheus-server \

     prom/prometheus


프로메테우스를 기동하였으면, 프로메테우스 모니터링 대상이 되는 프로메테우스의 노드(VM)의 지표를 수집하여 프로메테우스로 전송하는 node exporter를 설치해서 기동해야 한다. node exporter는 머신의 CPU,메모리,네트웍등과 같은 메트릭을 수집해서 프로메테우스가 가지고 갈 수 있도록 한다.

마찬가지로 도커 이미지로 기동하는데, quay.io/prometheus/node-exporter 의 이미지를 사용한다. 


docker run -d \

   -v "/proc:/host/proc" \

   -v "/sys:/host/sys" \

   -v "/:/rootfs" \

   --net="host" \

   --name=prometheus \

   quay.io/prometheus/node-exporter:v0.13.0 \

     -collector.procfs /host/proc \

     -collector.sysfs /host/sys \

     -collector.filesystem.ignored-mount-points "^/(sys|proc|dev|host|etc)($|/)"


node exporter 가 제대로 작동하는지 확인하려면, 

% curl https://{프로메테우스 서버 IP}:9100/metrics

명령을 실행해보면 다음과 같이 메트릭 정보들이 리턴되는 것을 확인할 수 있다. 

흥미로운것이 metric 수집을 HTTP GET 방식으로 하도록 되어 있다. 

이 관점에서 봤을때 구현이 매우 쉬울것 같은 장점도 있고, 별도의 포트를 오프하지 않아도 되는 장점은 있지만, 보안적으로 어떻게 접근 제어등을 할지는 나중에 별도로 한번 찾아봐야 하지 않을까 싶다. 


# HELP go_gc_duration_seconds A summary of the GC invocation durations.

# TYPE go_gc_duration_seconds summary

go_gc_duration_seconds{quantile="0"} 3.9293000000000005e-05

go_gc_duration_seconds{quantile="0.25"} 3.9293000000000005e-05

go_gc_duration_seconds{quantile="0.5"} 5.0119000000000006e-05

go_gc_duration_seconds{quantile="0.75"} 5.0119000000000006e-05

go_gc_duration_seconds{quantile="1"} 5.0119000000000006e-05

go_gc_duration_seconds_sum 8.9412e-05

go_gc_duration_seconds_count 2

# HELP go_goroutines Number of goroutines that currently exist.

# TYPE go_goroutines gauge

go_goroutines 8

# HELP go_memstats_alloc_bytes Number of bytes allocated and still in use.

# TYPE go_memstats_alloc_bytes gauge

go_memstats_alloc_bytes 6.234016e+06

# HELP go_memstats_alloc_bytes_total Total number of bytes allocated, even if freed.

# TYPE go_memstats_alloc_bytes_total counter


대쉬보드 접속

프로메테우스와 exporter 가 기동이되었으면, 메트릭이 제대로 수집이 되는지 확인하자. 

http://{프로메테우스 서버 ip}:9090 에 접속하면, 대쉬보드가 나오는데, 검색 쿼리 부분에 보고 싶은 메트릭에 대한 쿼리를 넣으면, 테이블이나 그래프 형태로 볼 수 있다.

아래는 node_cpu 항목을 넣어서 프로메테우스가 기동 중인 서버의 CPU 사용률을 모니터링해서 그래프로 나타낸 화면이다. 



본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

프로메테우스 #1 기본 개념과 구조

조대협 (http://bcho.tistory.com)


프로메테우스는 오픈 소스 기반의 모니터링 시스템이다. 

ELK 와 같은 로깅이 아니라, 대상 시스템으로 부터 각종 모니터링 지표를 수집하여 저장하고 검색할 수 있는 시스템이다. 

구조가 간단해서 운영이 쉽고, 강력한 쿼리 기능을 가지고 있으며, 그라파나(Grafana) 를 통한 시각화를 지원한다. 무엇보다 넓은 오픈 소스 생태계를 기반으로 해서, 많은 시스템을 모니터링할 수 있는 다양한 플러그인을 가지고 있는 것이 가장 큰 장점이다. 

특히 이런 간편함 때문에 특히나 쿠버네티스의 메인 모니터링 시스템으로 많이 사용되면서 요즘 특히 더 주목을 받고 있다. 

기본 구조

프로메테우스의 기본적인 아키텍처 부터 살펴보자

먼저 수집 저장 저장 아키텍처를 보면 다음과 같다. 




메트릭 수집 부분

수집을 하려는 대상 시스템이 Target system이다. MySQL이나, Tomcat 또는 VM 과 같이 여러가지 자원이 모니터링 대상이 될 수 있다. 이 대상 시스템에서 메트릭을 프로메테우스로 전송하기 위해서는 Exporter 라는 것을 사용한다. (다른 방법도 있지만 이는 나중에 따로 설명한다. )

풀링 방식

프로메테우스가 Target System에서 메트릭을 수집하는 방식은 풀링 방식을 사용한다. 프로메테우스가 주기적으로 Exporter로 부터 메트릭 읽어와서 수집하는 방식이다. 보통 모니터링 시스템의 에이전트 들은 에이전트가 모니터링 시스템으로 메트릭을 보내는 푸쉬 방식을 사용한다. 특히 푸쉬 방식은 서비스가 오토 스켈링등으로 가변적일 경우에 유리하다. 풀링 방식의 경우 모니터링 대상이 가변적으로 변경될 경우, 모니터링 대상의 IP 주소들을 알 수 가 없기 때문에 어려운 점이 있다. 예를 들어 웹서버 VM 2개의 주소를 설정 파일에 넣고 모니터링을 하고 있었는데, 오토 스케일링으로 인해서 VM이 3개가 더 추가되면, 추가된 VM들은 설정 파일에 IP가 들어 있지 않기 때문에 모니터링 대상에서 제외 된다. 

이러한 문제를 해결하기 위한 방안이 서비스 디스커버리라는 방식인데, 특정 시스템이 현재 기동중인 서비스들의 목록과 IP 주소를 가지고 있으면 된다. 예를 들어 앞에서 VM들을 내부 DNS에 등록해놓고 새로운 VM이 생성될때에도 DNS에 등록을 하도록 하면, DNS에서 현재 기동중인 VM 목록을 얻어와서 그 목록의 IP들로 풀링을 하면 되는 구조이다.

서비스 디스커버리 (Service discovery)

그래서 프로메테우스도 서비스 디스커버리 시스템과 통합을 하도록 되어 있다. 앞에서 언급한 DNS나, 서비스 디스커버리 전용 솔루션인 Hashicorp사의 Consul 또는 쿠버네티스를 통해서, 모니터링해야할 타겟 서비스의 목록을 가지고 올 수 있다. 

Exporter

Exporter는 모니터링 에이전트로 타겟 시스템에서 메트릭을 읽어서, 프로메테우스가 풀링을 할 수 있도록 한다. 재미 있는 점은 Exporter 는 단순히 HTTP GET으로 메트릭을 텍스트 형태로 프로메테우스에 리턴한다. 요청 당시의 데이타를 리턴하는 것일뿐, Exporter 자체는 기존값(히스토리)를 저장하는 등의 기능은 없다. 

Retrieval

서비스 디스커버리 시스템으로 부터 모니터링 대상 목록을 받아오고, Exporter로 부터 주기적으로 그 대상으로 부터 메트릭을 수집하는 모듈이 프로메테우스내의 Retrieval 이라는 컴포넌트이다.

저장

이렇게 수집된 정보는 프로메테우스 내의 메모리와 로컬 디스크에 저장된다. 뒷단에 별도의 데이타 베이스등을 사용하지 않고, 그냥 로컬 디스크에 저장하는데, 그로 인해서 설치가 매우 쉽다는 장점이 있지만 반대로 스케일링이 불가능하다는 단점을 가지고 있다.  대상 시스템이 늘어날 수 록 메트릭 저장 공간이 많이 필요한데, 단순히 디스크를 늘리는 방법 밖에 없다. 


프로메테우스는 구조상 HA를 위한 이중화나 클러스터링등이 불가능하다. (클러스터링 대신 샤딩을 사용한다. HA는 복제가 아니라 프로메테우스를 두개를 띄워서 같은 타겟을 동시에 같이 저장 하는 방법을 사용한다. 이 문제에 대한 해결 방법은 Thanos 라는 오픈 소스를 사용하면 되는데, 이는 다음에 다시 설명하도록 한다. )

서빙

이렇게 저장된 메트릭은 PromQL 쿼리 언어를 이용해서 조회가 가능하고, 이를 외부 API나 프로메테우스 웹콘솔을 이용해서 서빙이 가능하다. 또한 그라파나등과 통합하여 대쉬보드등을 구성하는 것이 가능하다. 


이 외에도 메트릭을 수집하기 위한 gateway, 알람을 위한 Alert manager 등의 컴포넌트등이 있지만, 기본적인 엔진 구조를 이해하는데는 위의 컴포넌트들이 중요하기 때문에, 이 컴포넌트들은 다른 글에서 설명하도록 한다.


프로메테우스 아키텍처에서 주의할점

간단하게 프로메테우스 아키텍처를 살펴보았는데, 이 구조에서 몇가지 생각해볼만한 점이 있다. 

어디까지나 근사치라는 점

일단 풀링 주기를 기반으로 메트릭을 가지고 오기 때문에, 풀링하는 순간의 스냅샷이라는 것이다. 15초 단위로 폴링을 했다고 가정했을때, 15초 내에 CPU가 올라갔다 내려와서, 풀링 하는 순간에는 CPU가 내려간 값만 관측이 될 수 있다. 스냅삿에 대한 연속된 모음일 뿐이고, 근사값의 형태라는 것을 기억할 필요가 있다. 

싱글 호스트

프로메테우스는 싱글 호스트 아키텍처이다. 확장이 불가능하고, 저장 용량이 부족하면 앞에서 언급한데로 디스크 용량을 늘리는 것 밖에 방안이 없다. 특히나 문제점은 프로메테우스 서버가 다운이 되거나 또는 설정 변경등을 위해서 리스타트등을 하더라도 그간에 메트릭은 저장이 되지 않고 유실이 된다는 점이다.




본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

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} --slave --master-host={master node의 주소}


이렇게 클러스터를 구성하면 아래와 같은 구조를 갖는다


특히 워크노드를 추가할때 별도의 설정이 필요없이 워커노드를 추가하면서 마스터 노드의 주소만 주면 되기 때문에, 스케일링이 편리하다. 

쿠버네티스에서 분산 부하 테스트

설정이 간단하고, 부하 테스트의 특성상 필요할때만 클러스터를 설치했다가 사용이 끝나면 없애는 구조로 사용을 하려면, 쿠버네티스에서 기동하면 매우 편리하다. 


특히 설치 및 설정을 Helm Chart로 만들어놓으면, 필요할때 마다 손쉽게 locust 클러스터를 설치했다가 사용이 끝나면 손쉽게 지울 수 있는데, Helm 공식 리파지토리에 등록된 locust chart는 https://github.com/helm/charts/tree/master/stable/locust 아쉽게도 locust 0.9를 기준으로 한다. 현재는 1.3 버전이 최신 버전인데, 0.9와 1.3은 설정고 TaskSet의 코딩 방식이 다소 변경되서, locust 0.9를 사용하게 되면, 현재 메뉴얼에 있는 일부 코드들을 사용할 수 없다. 

그래서, 스스로 Helm Chart를 만들어서 사용하기를 권장한다. 


좋은 소식중의 하나는 구글 클라우드에서 Locust 를 쿠버네티스에서 분산 부하 테스팅을 할 수 있는 가이드 문서를 제공하고 있으니, 이를 참조하면 손쉽게 사용이 가능하다.

https://cloud.google.com/solutions/distributed-load-testing-using-gke

단, helm chart 형태로는 제공하지 않으니, 스스로 Chart를 만들기를 권장한다. Chart를 만들때 기존 Chart 구조를 참고하기를 권장하는데, https://github.com/helm/charts/tree/master/stable/locust 를 보면, locust의 이미지 버전이나, 설정을 Helm의 values.yaml로 빼거나 또는 CLI parameter로 처리할 수 있게 하였고, 특히 아래 task files를 설정하는 방법이 매우 흥미로운데, 


task file을 도커 이미지 내에 넣는 방식이 아니라 file (또는 directory) 형태의 configmap으로 빼서, locust pod가 기동될때, 이 파일(디렉토리)를 마운트해서 스크립트를 읽어서 적용하는 구조를 가지고 있다.


위에서 언급한 구글 클라우드 플랫폼의 가이드는 task 파일을 docker 이미지로 매번 빌드하기 때문에, 다소 설치가 복잡해질 수 있다는 단점이 있다. 


그러면 구글 클라우드 플랫폼에서 제공하는 예제 파일들을 살펴보자

https://github.com/GoogleCloudPlatform/distributed-load-testing-using-kubernetes 리포에 저장이 되어 있는데, 

/docker-image 디렉토리

이 디렉토리에는 locust 도커 컨테이너를 만들기 위한 설정 파일들이 들어 있다. 

Dockerfile의 내용을 보면 아래와 같다.

# Start with a base Python 3.7.2 image

FROM python:3.7.2

 

# Add the licenses for third party software and libraries

ADD licenses /licenses

 

# Add the external tasks directory into /tasks

ADD locust-tasks /locust-tasks

 

# Install the required dependencies via pip

RUN pip install -r /locust-tasks/requirements.txt

 

# Expose the required Locust ports

EXPOSE 5557 5558 8089

 

# Set script to be executable

RUN chmod 755 /locust-tasks/run.sh

 

# Start Locust using LOCUS_OPTS environment variable

ENTRYPOINT ["/locust-tasks/run.sh"]


주의 깊게 살펴볼 부분은 아래 두줄이다. 

ADD locust-tasks /locust-tasks

RUN pip install -r /locust-tasks/requirements.txt


첫번째는 locust task 스크립트를 /locust-tasks 디렉토리에 복사하는 부분이다. 

그리고 두번째는 스크립트에서 사용하는 파이썬 라이브러리를 설치하는 부분이다. 

kubernetes-config 디렉토리


locust-master-controller.yaml

apiVersion: "extensions/v1beta1"

kind: "Deployment"

metadata:

 name: locust-master

 labels:

   name: locust-master

spec:

 replicas: 1

 selector:

   matchLabels:

     app: locust-master

 template:

   metadata:

     labels:

       app: locust-master

   spec:

     containers:

       - name: locust-master

         image: gcr.io/[PROJECT_ID]/locust-tasks:latest

         env:

           - name: LOCUST_MODE

             value: master

           - name: TARGET_HOST

             value: https://[TARGET_HOST]

         ports:

           - name: loc-master-web

             containerPort: 8089

             protocol: TCP

           - name: loc-master-p1

             containerPort: 5557

             protocol: TCP

           - name: loc-master-p2

             containerPort: 5558

             protocol: TCP


이 파일은 master node를 배포하기 위한 deployment 정의다. 주의 깊게 살펴볼 부분은 아래 두 라인이다. image는 앞에서 만든 task 스크립트가 포함된 locust 도커 이미지를 정의 하는 부분이고, 두번째는 부하 테스트 대상이 되는 타겟 호스트 주소를 정의하는 부분이다. 


image: gcr.io/[PROJECT_ID]/locust-tasks:latest

value: https://[TARGET_HOST]


다음은 locust-master-service.yaml 파일이다.

kind: Service

apiVersion: v1

metadata:

 name: locust-master

 labels:

   app: locust-master

spec:

 ports:

   - port: 8089

     targetPort: loc-master-web

     protocol: TCP

     name: loc-master-web

   - port: 5557

     targetPort: loc-master-p1

     protocol: TCP

     name: loc-master-p1

   - port: 5558

     targetPort: loc-master-p2

     protocol: TCP

     name: loc-master-p2

 selector:

   app: locust-master

 type: LoadBalancer


앞서 정의한 master node를 External IP (Load Balancer)로 밖으로 빼서, 웹 콘솔 접속등을 가능하게 하는 설정인데, 주의할점은 locust 웹 콘솔은 별도의 사용자 인증 기능이 없기 때문에, 위의 설정을 그대로 사용하면, 인증 기능이 없는 웹콘솔이 인터넷에 그래도 노출이 되기 때문에, 권장하지 않는다.


ClusterIP로 Service를 정의한 후, kubectl의 port forwarding 기능을 사용하거나 또는 앞에 인증용 프록시 서버를 두는 것을 권장한다. 구글 클라우드의 경우에는 Identity Aware Proxy(IAP)라는 기능을 이용하여, 구글 클라우드 계정으로 로그인을 해야 웹사이트를 접근할 수 있는 프록시 기능을 제공한다. 


마지막으로 locust-worker-controller.yaml 파일을 정의한다.

# Copyright 2015 Google Inc. All rights reserved.

#

# Licensed under the Apache License, Version 2.0 (the "License");

# you may not use this file except in compliance with the License.

# You may obtain a copy of the License at

#

#     http://www.apache.org/licenses/LICENSE-2.0

#

# Unless required by applicable law or agreed to in writing, software

# distributed under the License is distributed on an "AS IS" BASIS,

# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.

# See the License for the specific language governing permissions and

# limitations under the License.

 

apiVersion: "extensions/v1beta1"

kind: "Deployment"

metadata:

 name: locust-worker

 labels:

   name: locust-worker

spec:

 replicas: 5

 selector:

   matchLabels:

     app: locust-worker

 template:

   metadata:

     labels:

       app: locust-worker

   spec:

     containers:

       - name: locust-worker

         image: gcr.io/[PROJECT_ID]/locust-tasks:latest

         env:

           - name: LOCUST_MODE

             value: worker

           - name: LOCUST_MASTER

             value: locust-master

           - name: TARGET_HOST

             value: https://[TARGET_HOST]

 


이 파일을 worker node 에 대항 설정으로 master node와 마찬가지로 target_host와 locust 이미지 경로만 지정해주면 된다. 


이 파일들을 배포하면, locust 가 실행 준비가 되고, 앞에서 정의한 master node의 서비스 주소로 접속하면 locust 웹 콘솔을 이용하여 부하 테스트를 진행할 수 있다. 


만약 동적으로 locust worker node의 수를 조절하고 싶으면, 

% kubectl scale deployment/locust-worker --replicas=20


명령을 이용하여 worker node pod의 수를 조절할 수 있다. 

본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

부하테스트를 위한 Locust

조대협 (http://bcho.tistory.com)


백앤드 개발을 하다보면 많이 사용되는 도구 중의 하나가 부하 테스트 툴인데, 대표적인 도구로는 Apache Jmeter, nGrinder,SOAP UI 등의 도구가 있지만 다소 사용이 어렵고 스케일링을 하는데 어려움이 있는데, locust라는 도구는 설치와 사용이 편리하고, 테스트 시나리오를 파이썬 스크립트로 작성을 하기 때문에 다양한 시나리오 구현이 가능하다. 특히 쿠버네티스에 쉽게 배포할 수 있도록 Helm으로 패키지화가 되어 있기 때문에, 필요한 경우 대규모 부하테스트 환경을 설치하고 테스트가 끝나면 쉽게 지워버릴 수 있다. 

(참고 : locust는 영어로 메뚜기라는 뜻인데, 부하를 주는 것을 swarming 이라고 표현하는게 메뚜기 떼로 부하를 비교한것이 재미있다.)


퀵스타트

간단하게 설치 및 테스트를 해보자. 

설치

설치는 파이썬만 설치되어 있으면 간단하게 pip 명령을 이용해서 설치 할 수 있다.

%python -m pip install locust

명령으로 설치 하면 된다.

설치 확인은 locust --version 명령으로 확인하면 된다.  이 방식이외에도, 이미 빌드된 도커 이미지를 사용해서 테스트를 하거나 또는 쿠버네티스에서 Helm으로 설치해서 실행하는 방법도 가능하다. 쿠버네티스에서 Helm을 사용하는 방법은 나중에 자세하게 다루도록 한다. 

간단한 부하 스크립트 생성

locust 부하테스트는 파이썬 스크립트를 실행하는 방식으로 하기 때문에, 부하테스트용 스크립트 파일을 작성해야 한다. 아래는 대상 호스트의 / 에 HTTP GET으로 요청을 보내는 스크립트이다. 스크립트 작성방법은 후에 다시 설명하도록 한다. 


from locust import HttpLocust,TaskSet,task,between

class MyTaskSet(TaskSet):

   @task

   def index(self):

       self.client.get("/")

class MyLocus(HttpLocust):

   task_set = MyTaskSet

   wait_time = between(3,5)

실행하기

locust 실행은 locust -f {스크립트 파일명} {웹포트번호} 형식으로 실행하면 된다.

locust 서버가 기동되고, 부하를 줄 준비가 된 상태가 된다. 실제 부하 생성은 locust 웹콘솔에 접속해서 해야 한다.  아래 스크립트는 8080트로 locust 웹 클라이언트를 기동하도록 한 명령이다. 

%locust -f ./locustfile.py --port 8080


http://localhost:8080 으로 접속하면 아래와 같이 웹 콘솔이 나온다. 


첫번째 인자는, 몇개의 클라이언트를 사용할것인지 (메뚜기를 몇마리 만들것인지)를 정의하고, 두번째는 Hatch rate 라고 해서, 초마다 늘어나는 클라이언트 수 이다. 처음에는 클라이언트가 1대로 시작되서, 위의 설정의 경우 초마다 하나씩 최대 30개까지 늘어난다.

그리고 마지막은 테스트할 웹 사이트 주소를 입력한다.


Start Swarming 버튼을 누르게 되면 부하테스트가 시작되서 아래와 같이 부하 테스트 화면이 실시간으로 출력된다. 



몇 위의 화면은 Total Request Per Second로, 초당 처리량이고, 두번째는 응답 시간, 그리고 마지막은 현재 클라이언트 수 를 모니터링 해준다. 


No Web

위의 부하테스트는 웹 콘솔을 열어서, 웹 사이트로 부하를 주는 시나리오인데, 웹 부하 테스트가 아니라, 데이타베이스의 부하테스트와 같은 경우에는 웹 사이트의 주소를 정의할 수 없다. 이런 경우에는 CLI로 실행이 가능한데, --no-web 옵션을 주면 된다.

%locust -f ./nested-locust.py --no-web -c 2 -r 1 


위의 명령은 nested-locust.py 파일을 실행하되, --no-web으로 웹으로 부하를 주지 않고, -c 2 로 2개의 클라인트에 대해서 -r 1 1초마다 클라이언트를 (2까지) 하나씩 올리는 부하 테스트 시나리오이다. 웹 UI는 테스트 상태를 모니터링 하고 사람이 쓰기 좋지만 만약에 테스트 과정을 CI/CD 파이프라인내에 넣거나 또는 자동화하고 싶을때는 이렇게 CLI 를 이용할 수 있다. 

코딩 방법

사용방법을 이해하였으면, 이제 스크립트 작성 방법을 살펴보자.

스크립트는 Locust (클라이언트/메뚜기)를 정의해서, Locust의 행동 시나리오 (TaskSet)를 정의해야 한다. 

Locust

지원되는 Locust 종류는 HttpLocust와, Locust 두가지가 있다. HttpLocust는 웹 부하테스트용 클라이언트이고 범용으로 사용할 수 있는 클라이언트 (예를 들어 데이타 베이스 테스트)용으로 Locust라는 클래스를 제공한다. 하나의 부하테스트에서는 한 타입의 클라이언트만이 아니라 여러 타입의 클라이언트를 동시에 만들어서 실행할 수 있다.

예를 들어서 하나의 부하 테스트에서 안드로이드용 클라이언트와, iOS용 클라이언트를 동시에 정의해서 부하 비율을 정의해서 테스트(안드로이드,iOS = 7:3으로) 하는 것이 가능하다.

TaskSet

클라이언트(메뚜기)를 정의했으면, 이 클라이언트가 어떻게 부하를 줄지 시나리오를 정의해야 하는데, 이를 TaskSet이라고 한다. 

TaskSet는 Task의 집합으로 예를 들어, 테스트 시나리오에 리스트 페이지 보기, 상품 선택하기, 댓글 달기 등의 Task등을 정의할 수 있다.

Task

Task는 @task 라는 어노테이션으로 정의하면, TaskSet이 실행될때, TaskSet안에 있는 task를 random 하게 선택해서 실행한다. 아래 예제를 보자


class MyTaskSet(TaskSet):

    wait_time = between(5, 15)


    @task(3)

    def task1(self):

        pass


    @task(6)

    def task2(self):

        pass


위의 예제는 task1과, task2 를 랜덤하게 선택해서 실행하게 하는데, 괄호안의 숫자는 가중치가 된다. 즉 위의 TaskSet은 task1과 task2를 3:6의 비율로 실행하도록 한다.

wait_time

Task를 실행한 다음에 다른 Task를 수행할때 까지 delay 타임을 줄 수 있는데, TaskSet 클래스에 wait_time이라는 attribute로 정의되어 있다. 여기에 값을 지정해주면, 그 시간만 기다렸다가 다음 task를 수행한다. 위의 예제에서는 between(5,15)를 이용해서 5~15초 사이 시간 만큼 랜덤하게 기다렸다가 다음 task를 실행하도록 하였다. 

TaskSequence  & seq_task

TaskSet의 다른 종류로 TaskSequence 라는 클래스가 있는데, TaskSet이 task를 랜덤하게 실행한다고 하면, TaskSequence는 Task를 순차적으로 실행한다. 웹 테스트를 보면, 웹사이트에서 로그인하고, 초기 화면을 들어가고, 상품 목록 페이지로 이동하고 다음 상품 상세 페이지를 보는 것과 같은 순차적인 테스트가 필요할 수 있는데, 이를 지원하기 위한것이 TaskSequence 이다.

TaskSet과 다르게, TaskSequence내에서 순차적으로 실행해야하는 task는 seq_task()로 정의하고, 괄호 안에는 그 순서를 정의한다. 

아래 예제를 보자


class MyTaskSequence(TaskSequence):

    @seq_task(1)

    def first_task(self):

        pass


    @seq_task(2)

    def second_task(self):

        pass


    @seq_task(3)

    @task(10)

    def third_task(self):

        pass


위의 예제는 first_task를 실행하고, 두번째는 second_task를 실행한 후에, 세번째는 third_task가 실행되는데, @task(10) 으로 지정되어 있기 때문에, 10번이 실행된다. 

Nesting

Locust에서 TaskSet은 다른 TaskSet을 호출(Nest) 하는 것이 가능하다. 

예를 들어 부하 테스트 시나리오에서, 게시판에 글을 쓰는 시나리오와 상품을 구입하는 시나리오가 하나의 클라이언트에서 동시에 일어난다고 했늘때, 게시판에 글을 쓰는 TaskSet과, 상품을 구입하는 TaskSet을 정의하고 전체 시나리오에서 이 두 TaskSet을 호출하는 것과 같이 반복적이고 재사용적인 시나리오를 처리하는데 사용할 수 있다. 

아래 예제를 보자, 아래 예제는 UserBahavior TaskSet에서 Nested 라는 TaskSet을 호출하는 예제이다. 


from locust import Locust,TaskSet,task,between


class Nested(TaskSet):

        @task(1)

        def task1(self):

                print("task1")


        @task(1)

        def task2(self):

                print("task2")


        @task(1)

        def stop(self):

                print("stop")

                self.interrupt()



class UserBehavior(TaskSet):

        tasks = {Nested:2}


        @task

        def index(self):

                print("user behavior task")



UserBehavior에는 index라는 Task와 Nested TaskSet이 정의되어 있고, Nested TaskSet은 가중치가 2로 되어 있기 때문에, index task에 비해서 2배 많이 호출된다.

Nested TaskSet은 task1,task2,stop을 가지고 있느넫, 각각 가중치가 1로 이 셋중 하나가 랜덤으로 실행되는데, Nested TaskSet이 실행이 시작되면, 계속 Nested TaskSet 안의 task들만 실행이 되고, 그 상위 TaskSet인 UserBehavior가 원칙적으로는 다시 호출되지 않는다. 즉 Nested TaskSet의 task들로 루프를 도는데, 그래서 stop task에 self.intrrupt를 호출해서, Nested TaskSet 호출을 멈추고, UserBehavior TaskSet으로 리턴하도록 하였다. 

Hook

TaskSet은 실행 전후에, Hook을 정의할 수 있다.

setup & teardown

setup과, teardown은 TaskSet이 생성되었을때와 끝나기전에 각각 한번씩만 수행된다. 

locust가 실행되면, TaskSet 별로 정의된 setup 메서드가 실행되고, 프로그램을 종료를 하면, 종료하기전에 teardown 메서드가 실행된다. 

setup과 teardown은 테스트를 위한 준비와 클린업등에 사용할 수 있는데, 예를 들어 테스트를 위한 데이타 베이스 초기화 등에 사용할 수 있다. 주의 할점은 클라이언트를 여러개 만든다고 하더라도, TaskSet의 setup과 teardown은 각각 단 한번씩만 실행이 된다.

on_start,on_stop

setup과 teardown이 전체 클라이언트에서 한번만 실행된다면, 클라이언트마다 실행되는 Hook은 on_start와  on_stop이 된다. 

on_start는 클라이언트가 생성될때 마다 한번씩 실행된다. 


from locust import Locust,TaskSet,task,between


class UserBehavior(TaskSet):

def setup(self):

print("nested SETUP");


def teardown(self):

print("nested TEAR DOWN");


def on_start(self):

print("nested on start");


def on_stop(self):

print("nested on stop");


@task(1)

def task1(self):

print("task1")


@task(1)

def task2(self):

print("task2")



class User(Locust):

task_set = UserBehavior

wait_time = between(1,2)


코드를 

%locust -f ./locust.py --no-web -c 2 -r 1 

명령으로 2개의 클라이언트를 실행하게 되면 on_start는 단 두번 실행이 된다.

Locust setup & teardown

TaskSet의 Hook에 대해서 알아봤는데,  테스트 클라이언트인 Locust class도, setup과 teardown hook을 가지고 있다. 하나의 Locust 클라이언트는 여러개의 TaskSet을 가지고 있기 때문에, TaskSet마다 정의된 setup과 teardown이 실행되지만, Locust는 하나만 존재하기 때문에, 전역적으로 setup과  teardown은 정확하게 단 한번만 수행이 된다. 

Locust와 TaskSet의 실행 순서를 보면 다음과 같다. 


실행 순서

  • Locust setup

  • TaskSet setup

  • TaskSet on_start

  • TaskSet tasks…

  • TaskSet on_stop

  • TaskSet teardown

  • Locust teardown




본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

Istio Traffic management

조대협 (http://bcho.tistory.com)


Istio의 기능중의 하나가, 들어오는 트래픽을 여러 서비스로 라우팅을 하거나, 또는 트래픽에 테스트를 위해서 인위적으로 장애를 만들어 내는 것과 같은 트래픽 관리 기능이 있다. 

이러한 기능을 사용하려면, Istio에서 트래픽 관리에 사용되는 컴포넌트들의 컨셉을 알아야 한다. 초기에 Kubernetes의 트래픽 관리 기능인 Service, Ingress와 개념이 헷갈렸는데,  잘 정리해놓은 문서가 있어서 개념을 잘 정리할 수 있었다. 

Istio 트래픽 관리 컴포넌트는 크게 Gateway, VirtualService, DestinationRule 3가지로 정의된다.

Gateway

Gateway는 외부로부터 트래픽을 받는 최앞단으로, 트래픽을 받을 호스트명과 포트, 프로토콜을 정의한다. 웹서버에서 버추얼 호스트를 정의하는 것과 같이 정의 된다.  

아래는 Gateway의 예제이다. 


apiVersion: networking.istio.io/v1alpha3

kind: Gateway

metadata:

  name: ext-host-gwy

spec:

  selector:

    app: my-gateway-controller

  servers:

  - port:

      number: 443

      name: https

      protocol: HTTPS

    hosts:

    - ext-host.example.com

    tls:

      mode: SIMPLE

      serverCertificate: /tmp/tls.crt

      privateKey: /tmp/tls.key



이 설정은 ext-host.example.com 로 HTTPS 프로토콜로 443 포트를 통해서 트래픽을 받겠다고 정의한것이다. 

Virtual Service

들어온 트래픽을 서비스로 라우팅 하는 기능이다. 쿠버네티스의 Service가 목적지가 되는 것이고, 실제로 Virtual Service의 기능은 URI 기반으로 라우팅을 하는 Ingress와 유사하다고 보면 된다.


클라이언트가 쿠버네티스의 Service를 호출할때 라우팅 규칙에 따라서 적절한 쿠버네티스 Service로 라우팅 해주는 기능을 한다. 

아래 예제를 보자


apiVersion: networking.istio.io/v1alpha3

kind: VirtualService

metadata:

  name: bookinfo

spec:

  hosts:

  - "*"

  gateways:

  - bookinfo-gateway

  http:

  - match:

    - uri:

        exact: /productpage

    - uri:

        prefix: /static

    - uri:

        exact: /login

    - uri:

        exact: /logout

    - uri:

        prefix: /api/v1/products

    route:

    - destination:

        host: productpage

        port:

          number: 9080


예제 출처: https://github.com/istio/istio/blob/master/samples/bookinfo/networking/bookinfo-gateway.yaml

hosts는 클라이언트가 요청한 request에 대해서 어떤 host를 호출한것을 처리할것인지를 결정한다. 여기서는 hosts: “*”로 하였기 때문에, 모든 서비스 호출에 대해서 이 Virtual Host가 라우팅 처리를 하는데, 모든 서비스 호출은 gateways: bookinfo-gateway를 이용하여, 어느 gateway에서 들어온 요청을 처리하는지 지정할 수 있다. 

즉 이 VirtualService는 bookinfo-gateway 를 통해서 들어온 모든 요청에 대해서 처리하게 된다. 


그 다음 http: 부분에서 URL 별로 라우팅을 하도록 정의하였다.

http: match: 부분을 보면 /product, /login,/logout은 exact로 정의가 되어 있기 때문에 이 URL로 매칭 되는 요청이나 또는 /static, /api/v1/products는 prefix로 정의되어 있기 때문에, /static, /api/v1/products URI로 시작하는 요청에 대해서 라우팅을 처리한다.


라우팅 Destination은 route: destination에 정의하는데 productpage 쿠버네티스 Service의 9080, 즉 products.{namespace}.svc.cluster.local 서비스로 포워딩이 된다. 


앞의 예제는 gateway를 통해서 들어온 트래픽을 처리하는 방법이었다. 다른 예제를 보자. 아래 Virtual Service는 gateway와 연동되어 있지 않고 reviews.prod.svc.cluster.local 서비스를 호출하는 요청에 대한 라우팅 규칙을 정의하였다.


apiVersion: networking.istio.io/v1alpha3

kind: VirtualService

metadata:

  name: reviews-route

spec:

  hosts:

  - reviews.prod.svc.cluster.local

  http:

  - name: "reviews-v2-routes"

    match:

    - uri:

        prefix: "/wpcatalog"

    - uri:

        prefix: "/consumercatalog"

    rewrite:

      uri: "/newcatalog"

    route:

    - destination:

        host: reviews.prod.svc.cluster.local

        subset: v2

  - name: "reviews-v1-route"

    route:

    - destination:

        host: reviews.prod.svc.cluster.local

        subset: v1

예제 출처 :https://istio.io/docs/reference/config/networking/virtual-service/ 


reviews.prod.svc.cluster.local을 호출하였을때 URI가 /wpcatalog 나 /consumercatalog로 시작한다면 이를 /newcatalog로 바꾼 후에, reviews.prod.svc.cluster.local 쿠버네티스 서비스를 호출하는데, subset이 v2로 되어 있기 때문에, reviews.prod.svc.cluster.local pod 중에 v2 subset으로만 라우팅 한다.  (subset이라는 부분이 있는데, 이 부분은 추후에 설명한다.)

만약 이 URI와 매칭되는 것이 없다면, 

  - name: "reviews-v1-route"

    route:

    - destination:

        host: reviews.prod.svc.cluster.local

        subset: v1

에 의해서 다른 모든 트래픽은 reviews.prod.svc.cluster.local pod 중에 v1 subset으로만 라우팅 된다.


다른 예제를 하나 더 보자

apiVersion: networking.istio.io/v1alpha3

kind: VirtualService

metadata:

  name: my-productpage-rule

  namespace: istio-system

spec:

  hosts:

  - productpage.prod.svc.cluster.local # ignores rule namespace

  http:

  - timeout: 5s

    route:

    - destination:

        host: productpage.prod.svc.cluster.local

예제 출처 : https://istio.io/docs/reference/config/networking/virtual-service/


이 예제는 productpage.prod.svc.cluster.local 쿠버네티스 서비스를 호출 하는 Virtual Service 인데, 별도의 라우팅 없이 productpage.prod.svc.cluster.local 를 그대로 호출하도록 정의하였는데, timeout: 5s 로 줘서, 해당 서비스가 5초 동안 응답이 없으면 timeout 처리를 하도록 하였다. 


Virtual Service의 개념을 이해할때 자칫 헷갈릴 수 있는데, 아래 두가지를 기억하면 이해에 도움이 된다. 

  • 쿠버네티스의 Ingress 처럼 들어오는 트래픽에 대해서 URI 나 Header 등 요청에 따른 라우팅을 한다

  • Virtual Service는 Gateway를 통해서 들어오는 트래픽을 받아서 Service로 라우팅 시킬 수 도 있고 또는 쿠버네티스 Service로 가는 요청에 대해서 라우팅을 할 수 도 있다. 

DestinationRule

Virtual Service가 쿠버네티스 Service로 트래픽을 보내도록 라우팅을 했다면, 그 다음 Destination Rule은 그 서비스로 어떻게 트래픽을 보낼것인가를 정의한다. (하나의 Detination Rule은 하나의 Service에 대해서만 정의한다)


Virtual Service가 라우팅을 해서 Service로 트래픽을 보내면, 실제로는 그 안에 있는 Pod 들에 라우팅이 되는데, 어느 Pod 들로 트래픽을 보낼지, 그리고, 어떻게 보낼지를 정의한다. 


아래 예제는 my-svc.{namespace}.svc.cluster.local 서비스로 보내는 트래픽을 어떻게 보낼지를 정의하였는데, my-svc.{namespace}.svc.cluster.local  를 version이라는 pod 의 label에 따라서 v1,v2,v3 로 그룹핑을 하였다. 이를 subset이라고 한다. 


apiVersion: networking.istio.io/v1alpha3

kind: DestinationRule

metadata:

  name: my-destination-rule

spec:

  host: my-svc

  trafficPolicy:

    loadBalancer:

      simple: RANDOM

  subsets:

  - name: v1

    labels:

      version: v1

  - name: v2

    labels:

      version: v2

    trafficPolicy:

      loadBalancer:

        simple: ROUND_ROBIN

  - name: v3

    labels:

      version: v3

예제 출처 : https://istio.io/docs/concepts/traffic-management/#destination-rules


그 후에 pod 간 로드 밸런싱 정책은 

  host: my-svc

  trafficPolicy:

    loadBalancer:

      simple: RANDOM

와 같이 디폴트는 RANDOM 로드 밸런싱을 정의하였지만 subset v2의 경우에는

  - name: v2

    labels:

      version: v2

    trafficPolicy:

      loadBalancer:

        simple: ROUND_ROBIN


와 같이 ROUND_ROBIN을 사용하도록 하였다. 

Destination Rule을 사용하면, 서비스로 트래픽을 보내더라도, pod의 label에 따라서 서비스내의 pod들에 골라서 트래픽을 보낼 수 있고, pod간의 로드밸런싱이나 여러 정책을 정의하는 것이 가능하다.


대략적으로 이 개념들을 정리해서 하나의 그림에 그려보면 다음과 같다



읽어볼만 한글


참고할 사항

Ingress-gateway라는 용어가 종종 나오는데, 이는 Kubernetes에서 Gateway 를 구현하기 위한 실제 Pod이다. Service + Deployment로 되어 있고, 스케일을 위해서 HPA를 적용할 수 있다.


Istio를 사용한다고 해서 외부에서 들어오는 트래픽을 반드시 Istio gateway를 사용해야 하는 것은 아니다. 기존의 Kubernetes Ingress를 그대로 사용할 수 도 있고, Kong 과 같은 API gateway를 사용하는 것도 가능하다.


다른 Service간의 통신은 아래 그림과 같이 pod → 다른 Service의 Pod를 호출할때, 중간에 Load balancer를 거치거나 하지 않고 아래 그림과 같이 Envoy Proxy를 통해서 바로 이루어진다. 생각해보니, ClusterIP는 원래 Load balancer를 거치지 않았어..


그림 원본 https://medium.com/@zhaohuabing/which-one-is-the-right-choice-for-the-ingress-gateway-of-your-service-mesh-21a280d4a29c


예제 코드 참고 https://istio.io/docs/concepts/traffic-management/


본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

리눅스 방화벽과 NAT를 위한 ipTables


서버에서 라우팅 설정을 하다보면, 다른 포트로 받아야 하는데, 로드밸런서나 방화벽등의 문제로 포트를 변경할 수 없는 경우가 있어서 A포트로 들어오는 트래픽을 B포트로 변경하고 싶을때가 있다.

또는 서버로 들어오는 트래픽을 IP등으로 선별적으로 받는 것과 같은 방화벽 역할이 필요한 경우가 있는데, 방화벽을 설치하지 않고 서버단에서 간단하게 하는 방법이 필요한 경우가 있는데, 이러한 용도를 위해서 사용할 수 있는 것이 ipTables이다. 


ipTables는 리눅스 firewall로 incoming & outgoing traffic을 rule에 따라 filtering 하는 기능을 가지고 있다. ipTables는 table이라는 단위를 가지고 있는데, 이 table 마다 룰을 정해서 룰에 매치되는 트래픽에 대해서 핸들링할 수 있는 기능이 있다. 

주로 사용되는 테이블은 다음과 같다

  • Filter table :  가장 많이 사용되는 테이블로, 트래픽에 대한 컨트롤을 하는 방화벽 역할로 사용된다.

  • NAT table :  들어오는 패킷을 다른 포트나 다른 호스트 서버로 라우팅 하는 역할을 한다.

  • Mangle table : 패킷의 헤더를 변경하는데 사용할 수 있다. (예 TTL 등)


각 테이블은 체인(CHAIN)으로 구성이 되는데, 각 단계별로 하는 역할이 다르다.


Filter table

먼저 Filter Table을 보면 다음과 같다. 

%iptabls -L -v

명령어를 이용하면 필터 테이블을 볼 수 있는데, 크게 Input,Forward,Output 체인으로 구성이 되어 있다. 

예를 들어 보면

%sudo iptables -A INPUT -i lo -j ACCEPT

는 모든 들어오는 트래픽에 대해서 Loopback interface는 모든 트래픽을 허용하도록 INPUT CHAIN을 설정한 것이다. 

만약 http,https,SSH 만 허용하려면 다음과 같이 사용하면 된다. 

%sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT

%sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT

%sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT


특정 IP에서 들어오는 트래픽을 허용하고자 하면 

sudo iptables -A INPUT -s 192.168.1.3 -j ACCEPT

게 설정하면 된다. 

반대로 특정 IP에서 들어오는 트래픽만 막고자 한다면 DROP을 하면 되는데, 

sudo iptables -A INPUT -s 192.168.1.3 -j DROP

명령을 사용하면 된다. 


등록된 rule을 삭제하려면

sudo iptables -L --line-numbers

명령을 사용하면, 등록된 룰이 번호와 함께 나오고 

sudo iptables -D INPUT 3

명령으로 3번째 룰을 삭제할 수 있다. 


iptables 명령어는 수정한 테이블과 룰은 메모리에만 남아 있기 때문에 재기동하면 삭제된다. 

그래서 영구 반영하기 위해서는

sudo /sbin/iptables-save

명령으로 저장해야 한다. 

NAT table

다음으로 유용하게 사용할 수 있는것이 NAT 테이블인데 들어온 트래픽을 다른 호스트로 라우팅 시키거나 또는 같은 호스트내의 다른 포트로 포워딩 시키는 것이 가능하다. 

패킷은 들어오면 아래와 같은 체인들을 거쳐가는데, 그림에서 보면 nat와 filter 체인이 섞여 있는 것을 볼 수 있다. 


트래픽은 들어오면 NAT의 PRE ROUTING을 거쳐, FILTER의 INPUT을 거쳐서 애플리케이션으로 들어갔다가 나올때 FILTER의 OUTPUT 체인과, NAT의 OUTPUT 체인을 거쳐서 최종적으로 NAT의 POSTROUTING 체인을 거쳐서 목적지로 라우팅 된다. 



그림 출처 : https://www.systutorials.com/816/port-forwarding-using-iptables/


이 과정에서 NAT 테이블의 체인 중 주로 사용되는 CHAIN을 보면

  • PREROUTING : 들어온 트래픽을 다른 호스트나 또는 같은 호스트의 다른포트로 포워딩 할때 사용된다.

  • POSTROUTING : 호스트에서 아웃바운드로 나가는 트래픽을 다른 IP나 포트로 포워딩 한다. 


예를 들어보면 아래는 80포트로 들어온 트래픽을 같은 호스트의 4000포트로 포워딩하는 설정이다. 


sudo iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 4000


참고로 이렇게 하면 외부에서 80 포트로 들어오는 트래픽은 4000으로 라우팅 되지만, localhost:80 으로 호출을하면 이는 라우팅이 되지 않는데, 이유는 localhost는 PREROUTING CHAIN을 타지 않기 때문이다. 그래서 만약 localhost에도 동일하게 작동하게 하려면 Output chain을 아래와 같이 설정해줘야 한다.

iptables -t nat -A OUTPUT -o lo -p tcp --dport 80 -j REDIRECT --to-port 8080

참고 : https://askubuntu.com/questions/444729/redirect-port-80-to-8080-and-make-it-work-on-local-machine


본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

API 게이트 웨이

What is API 게이트웨이

API 게이트웨이는 API 클라이언트와 서비스 사이에 프록시 처럼 위치하여, 클라이언트로 부터 온, API 요청을 받아서, 서비스로 라우팅 하는 역할을 한다. 

각각의 서비스에서 구현해야 하는 기능을 API 게이트웨이단으로 통합함으로써, 서비스 개발을 간편하게 할 수 있고, 메세지 포맷 변경이나, 플로우 컨트롤과 같은 고급 기능을 사용하여, 기존 API 호출에 추가적인 기능을 더할 수 있는 유연성을 더할 수 있게 된다.


여러가지 기능이 있겠지만, 크게 아래와 같이 5가지로 나눠볼 수 있다.

  • 인증

  • 모니터링,로깅

  • 플로우 컨트롤

  • 메시지 변경

  • 오케스트레이션(매쉬업)





<출처 : 마이크로소프트 애저 홈페이지>


인증

API를 호출할때, API 호출에 대한 인증을 수행한다. 서버간의 API 통신일 경우에는 간단하게 API 키를 사용하는 방법등이 있고, 다수의 클라이언트 (모바일 단말, 웹 자바스크립트 클라이언트)의 경우에는 사용자 계정 인증 후에, JWT 토큰을 발급하는 방식이 있다. 

모니터링 & 로깅

API 호출에 대한 모니터링을 통해서 API 별 응답시간, 장애율,호출 횟수를 모니터링 할 수 있게 하고, 경우에 따라서 개별 API 호출을 로깅한다. 

Metering & Charging

API를 대외로 서비스 하는 경우, API의 호출량을 모니터링 해야 하는데, 이 양을 기반으로 해서 API 서비스 호출 횟수를 통제하거나 또는 유료 API의 경우에는 과금을 해야 하기 때문에, 대외로 서비스를 하는 오픈 API 플랫폼인 경우에는 이러한 기능이 필요하다. 

메시지 플로우 컨트롤

메시지 플로우 컨트롤은 클라이언트로 부터 들어온 메시지의 흐름을 바꾸는 방법인데, 예를 들어 같은 API라도 버전에 따라서 구버전과 새버전으로 트래픽을 9:1로 라우팅하는 카날리 배포 방식이라던지, 들어온 API를 클라이언트의 위치에 따라 미국이나,한국에 있는 서비스로 라우팅을 하는 등의 로직을 구현할 수 있다. 

Limiting (throttling)

조금 더 고급화된 구현방법으로는 Limiting 기법이 있는데, 특정 API에 대해서 정해진 양 이상의 트래픽을 받지 못하도록 하여, 서비스를 보호하거나 또는 유료 API 서비스인 경우 QoS (Quality Of Service)를 보장하기 위해서 특정 양까지만 트래픽을 허용하도록 컨트롤할 수 있다. 

메시지 변환

메시지 변환은 고급 기능 중의 하나인데, 헤더에 있는 내용을 메시지 바디로 붙이거나, 다른 API를 호출해서 응답메시지를 두 API를 합해서 응답을 해주는 기능등을 구현할 수 있다. 

프로토콜 변환

그외에도 서로 다른 프로토콜에 대한 변환이 가능한데, 예를 들어 클라이언트로 부터는 gRPC로 호출을 받고, API서버로는 REST로 호출한다던가. SOAP/XML 기반의 메시지를 REST로 변환하는 등의 기능 구현이 가능하다. 

호출 패턴 변환

API 서버가 큐를 기반으로한 비동기 메시지 처리 패턴일때, API 게이트 웨이에서 이를 동기화 처리 패턴으로 바꿔서, 클라이언트 입장에서는 동기로 호출을 하면, API 서버에서는 비동기로 호출하는 형태와 같이 호출 패턴을 변화시킬 수 있다. 

오케스트레이션(매시업)

API 클라이언트가 한번 호출을 할때, 동시에 여러개의 API를 호출하도록 API 게이트웨이에서 호출을 해주는 방식이다. 예를 들어 API 클라이언트가 “상품 구매" 라는 API를 호출 하였을때, API 게이트웨이가 “상품 구매" API 서비스를 호출하고, “상품 추천" 이라는 API도 호출해서, 클라이언트로 구매 완료 메시지와 함께 추천 상품 리스트를 한번에 리턴하는 방식이다. 


경량형 게이트웨이와 중량형 게이트웨이

API 게이트 웨이는 근래에 마이크로 서비스가 각광을 받으면서 언급되기 시작하고 있지만, 사실 API 게이트 웨이라는 기술 자체는 오래된 기술이다. API 게이트 웨이 이전에는 SOA 제품군의 일부로 ESB (Enterprise Service Bus)가 SOAP/XML 웹서비스 기반으로 이러한 역할을 해주었는데, 잘못된 구현 패턴을 사용해서 문제가 된 케이스가 많다. 예를 들어서 과도하게 오케스트레이션 기능을 사용하였을 경우 API 게이트웨이 자체에 부하가 걸려서 전체 API 서비스에 성능 문제를 야기 하거나, 또는 파일 업로드 요청을 API 게이트 웨이를 통해서 함으로써 게이트웨이의 부하때문에 성능 문제가 생기는 경우가 있었다. 

SOAP/XML에서 REST API로 오면서, API 게이트웨이도 이러한 문제를 피하는 패턴형식으로 API 게이트 웨이가 포지셔닝이 달라졌다. 사실 매시업이나, 메시지 라우팅, 메시지 변환등과 같은 기능들은 사실 사용되는 일이 그렇게 많지 않고, 클라이언트단에서 처리해도 충분하기 때문에, 이러한 고급 기능 보다는 API 인증, 로깅/모니터링 위주의 최소한의 기능만 가지면서 경량화된 형태로 배포 및 운영이 간편한 경량형 API 게이트 웨이들이 소개 되기 시작하였고, 반대로 오픈 API를 고객을 대상으로 제공하면서 메시지 변환이나, 과금등 고급 기능을 제공하는 중량형 API 게이트 웨이들도 꾸준히 제품들이 제공되고 있다.


이러한 제품들에 대한 명시적인 구분은 없지만, 필자의 기준으로 봤을때, 경량형 API 게이트 웨이는 Kong등을 들 수 있고, 중량형 API 게이트 웨이는 APIgee, MuleSoft 등을 들 수 있다. 


전통적으로 중량형 API 게이트웨이의 아키텍쳐 구조는 API 게이트웨이가 클러스터 형태로 배포 된 후에, 그 뒤에 API 서버들이 배포되는 형태라면, 경량형 API 게이트웨이는 nginx나 node.js와 같은 가벼운 프록시 서버로 배포하고, 용량이 필요하다면 개별의 인스턴스들을 스케일링으로 늘리는 방법을 사용한다. 근래에는 중량형 API 게이트 웨이도 이러한 구조를 많이 참고해서 구조를 개선하고 있다. 

쿠버네티스와 API 게이트 웨이

이러한 API 게이트웨이들이 쿠버네티스의 등장과 함께 주목 받으면서, 쿠버네티스 지원을 넓혀나가고 있는데, 이 과정에서 흥미로운 아키텍쳐 구성을 보인다. 쿠버네티스는 이미 Service라는 리소스를 통해서 마이크로 서비스를 정의할 수 있고, Service를 묶어서 로드밸런싱을 하는 Ingress라는 리소스를 가지고 있다. 즉 Ingress는 Service간의 라우팅을 할 수 있는 일종의 초경량 API 게이트웨이로써의 기능을 가지는 구조인데, API 게이트웨이의 쿠버네티스 연동은, 새롭게 애플리케이션을 배포하고 설정하는 방식이 아니라 쿠버네티스 리소스 자체에 API 게이트웨이를 녹이는 방식으로 접근하고 있다.


아래 Kong API 게이트웨이의 구조를 보면, Kong 전용으로 컨테이너를 배포하지 않고, Kong API 게이트웨이용 Ingress를 정의해서 사용자가 Ingress를 사용하게 되면 API 게이트웨이를 사용할 수 있게 하였고, 메시지 변환이나 기타 기능이 필요할 경우 이를 CRD(Custom Resource Definition) 로 미리 등록해놔서 이를 사용하도록 하고 있다. 



<Kong API 게이트 웨이 아키텍처 출처  > 


구글의 Apigee의 경우에는 Apigee Hybrid라는 이름으로 Kubernetes를 지원하는데, 구조는 Istio Ingress를 앞단에 둬서 라우터로 이용하고 API 게이트웨이에서 처리하는 각종 로직을 Ingress 뒤에 Pod(아래 그림 4번)로 배포하여 기능을 수행하도록 하고 있다. 

API 호출을 통과 시키는 프록시는 이렇게 단순화 시키고, 관리 콘솔은 구글 클라우드로 위치 시켜서 운영을 최대한 단순화 시켰다. 


<출처 : 구글 apigee hybrid 문서 > 

구글의 API 게이트 웨이 - Cloud Endpoint

구글의 Cloud Endpoint는 경량형 API이다. 

기본적으로 nginX로 배포되서 프록시 처럼 동작하며, 기능은 API 인증과 모니터링/로깅정도 밖에 없지만 구조와 기능이 단순하기 때문에 사용이 편리하며, 또한 nginX 기반의 배포 방식으로 인해서 구글 클라우드 뿐만 아니라, 다른 클라우드나 ON-PREM에도 사용이 가능하다는 장점이 있다. 


구조는 다음과 같이 되어 있다.



<그림. Cloud Endpoint ESP 아키텍쳐 / 출처 >


ESP는 Cloud Endpoint의 Proxy, 즉 nginX를 이야기 한다. 프록시는 실제로 쿠버네티스 클러스터에 배포되고, 모니터링과 로깅, 컨트롤러는 구글 클라우드의 콘솔을 이용하게 된다. 

쿠버네티스에 배포하는 형태는 다음 그림과 같다. 

애플리케이션 컨테이너와 함께, 같은 Pod로 패키징 되고, ESP에서는 애플리케이션으로 트래픽을 localhost로 포워딩한다. 


<그림. ESP의 쿠버네티스 배포 형태 >


이런 구조를 가지기 때문에, Ingress, Istio 등 다른 쿠버네티스 플랫폼들과 유연하게 통합이 된다. 

API 인증은 여러가지 방법을 지원하는데, Firebase authentication, Google ID,SAML(SSO) 방식으로 사용자를 인증한후에, API 키(JWT)를 발급하는 방법이나, 서버간일 경우 Service Account를 사용하는 방법 또는 단순하게 API KEY를 사용하는 방법이 있고 또는 Custom 인증을 구현하여 JWT 토큰으로 인증할 수 있다. 인증 방식은 이 문서를 참고하면 된다.

로깅/모니터링

로깅과 모니터링은 End Point 콘솔에서 볼 수 있으며, 아래와 같이 서비스 단위로 응답 시간과 에러율등을 출력해준다


OPEN API (Swagger) 기반 포탈

그리고 중요한 기능중의 하나인데, API 스펙 문서를 포탈 형태로 보여준다. Swagger 문서 형태로 작성을 하면 아래와 같이 독립된 웹사이트 형태로 API 스펙 문서를 보여준다.


<그림. Cloud endpoint developer portal / 출처


멀티/하이브리드 클라우드

마지막으로, Cloud End Point는 ngnix 기반으로 배포가 가능하기 때문에, 구글 클라우드 뿐 아니라 타 클라우드나 온프렘 데이타 센터내에도 프록시(ESP)를 배포해서 사용하는 것이 가능하다. 


참고 문서


본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

오픈소스 API 게이트웨이 Kong

#3 쿠버네티스 Kong

조대협 (http://bcho.tistory.com)


Kong Kubernetes

API 게이트웨이가 마이크로서비스의 중요 컴포넌트이다 보니, Kong이 마이크로 서비스에 적합한 K8S (aka. 쿠버네티스)에 어떻게 적용될 수 있는지가 궁금해서 아키텍쳐 관련 설명 내용을 찾아보았다. https://konghq.com/blog/kong-kubernetes-ingress-controller/ (아래 그림은, 이 동영상에서 캡춰하여 사용하였다.) 에 보면 Kong summit에서 발표된 영상이 있는데, 정리가 매우 잘되어 있다. 


기본 컨셉을 먼저 요약해보자면, Kong의 리소스들은 K8S의 리소스로 등록되어 사용되게 된다. API 게이트 웨이는 Ingress로 등록되고, Plugin들은 CRD (Kubernetes Custom Resource Definition)으로 등록되어 적용된다. 즉 별도의 Kong 설정을 하는 것이 아니라 쿠버네티스 리소스로 쿠버네티스 아키텍쳐에 따라서 등록이 된다는 이야기이다. 별도의 서비스나 서버를 기동하는 것이 아니라 K8S의 일부로 사용할 수 있도록 하고 있다. (동영상에서도 나오지만 Kong이 K8S 1’st citizen임을 계속 강조하고 있다.)


Kong의 쿠버네티스내의 배포 아키텍쳐는 다음과 같다. 

먼저 관리 서버 부분인 Control plane과, API 게이트 웨이 부분인 Data plane으로 나뉘어 진다. 


Control plane에는 Ingress controller가 있고, 이는 K8S의 API 서버와 통신을 통해서 명령을 받는다. 그리고 이 설정 정보를 psql 데이타 베이스에 저장한다. 

저장된 설정 정보는 Data plane 즉, API 게이트웨이 인스턴스에 반영이 된다. 

(만약에 psql이 죽어도 dataplane에 있는 프록시는 설정을 저장하고 있기 때문에 문제 없다.)


Kong의 리소스 맵핑

그러면 Kong API 게이트웨이에서 사용하는 리소스들은 어떻게 쿠버네티스 리소스로 맵핑이 될가?

쿠버네티스의 리소스를 Kong의 리소스로 맵핑(Translate) 해서 서비스 한다. 

아래는 Kong에서 사용하는 리소스들이다. 


이를 쿠버네티스 리소스로 맵핑한것은 다음과 같다. 




  • Route는 Ingress rule로 맵핑이 되고

  • Service 는 쿠버네티스의 Service로 맵핑 된다.

  • Target은 쿠버네티스의 pod가 되고

  • Upstream은 healthcheck와 LB로 정의 된다. 


게이트웨이에서 사용되는 플러그인 (라우팅이나 RateLimiting, Logging, 인증등)은 K8S의 CRD로 정의되어 있다.  CRD를 사용하게 되면 Ingress 에 반영되어서 사용된다.  

아래는 Rate limiting 플러그인을 K8S에서 CRD로 정의해서 사용한 예제이다

플러그인 CRD들은 ingress에 붙어서 사용된다. 




Ingress는 CRD와 함께 Limit rating, Logging, Routing등을 제공한다. 이러한 기능들은 대부분 Istio와 같은 Service mesh에도 있는데, Istio와 같은 서비스 메쉬와 비교할 경우, JWT 등  인증이 안되는 부분이 있는데, 이 부분을 보면 다소 차이가 있다. 


결론적으로 정리를 해보자면, Kong API 게이트웨이는 K8S에서는 Ingress로 정의되고, 플러그인은 CRD로 제공된다. Control Plane을 통해서 설정 정보가 저장되는 형태이다. 


쿠버네티스에 Kong을 설치하는 가이드는  https://docs.konghq.com/install/kubernetes/ 있는데, 설치는 Helm이나 Kustomize로 도 가능한데, 데이타 베이스에 대한 내용을 보면, 다음과 같다. 


"We recommend running Kong in the in-memory (also known as DB-less) mode inside Kubernetes as all the configuration is stored in Kubernetes control-plane. This setup drastically simplifies Kong’s operations as one doesn’t need to worry about Database provisioning, backup, availability, security, etc."


별도의 데이타 베이스 설치는 권장하지 않고, DB-less 모드로 설정하기를 권장하고 있다. 

YAML 파일로 설정을 정의해서 변경할 경우, 설정이 어떻게 전체 게이트웨이로 전파가되는지 등은 실제 테스트를 해봐야 알 수 있을듯



본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

오픈소스 API 게이트웨이 Kong

#2 아키텍쳐와 간단한 테스트

조대협 (http://bcho.tistory.com)

Kong 아키텍쳐

Kong API 서버의 배포 아키텍쳐는 다음과 같다. 


출처 : stackoverflow.com

Kong API 게이트웨이 각각 nginx 로 되어 있고, DB 모드의 경우에는 별도의 데이타 베이스 인스턴스를 사용한다. 지원되는 데이타 베이스로는 카산드라나 postgres를 사용할 수 있다. 

데이타 베이스를 사용하더라도 변경된 설정은 인스턴스에 바로 반영되지 않는다. 각 인스턴스가 설정 내용을 캐슁하기 때문인데, 캐쉬가 리프레쉬되어야 설정 내용이 반영된다. 

클러스터에서 Kong API 게이트웨이 인스턴스간의 로드 밸런싱을 하기 위해서는 각 인스턴스 앞에 로드밸런서를 배치 시킨다. 만약에 Session Affinity가 필요하다면 L4에서 IP나 Session based affinity를 설정해야 한다. 


Kong API 게이트웨이에서 각종 기능들은 nginX의 Lua 스크립트 모듈은 OpenResty를 이용한다. 

간단한 API 테스트

개념 이해가 끝났으면 간단한 테스트를 해보자

파이썬으로 간단한 API 서버를 구현하였다. app.py로 simpleapi:9001/api URL로 HTTP GET으로 간단하게 서빙하는 API가 있다고 할때


kong.yml을 다음과 같이 구현한다. 

_format_version: "1.1"


services:

- name: simpleapi

  url: http://simpleapi:9001

  routes:

  - name: simpleapi-route

    paths:

    - /simpleapiservice



simpleapi라는 이름으로 서비스를 등록하고 API 서버의 호스트 경로는 http://simpleapi:9001로 등록한다.

위의 설정은 {Kong IP}/simpleapiservice URL을 —> http://simpleapi:9001로 라우팅하도록 한 설정이다.

%curl localhost:8000/simpleapiservice/api


실행하면 http://simpleapi:9001/api 를 호출한 결과가 리턴된다. 


본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요


xip.io is dns proxing service. It is easy to assign dns name to ip address.

This is way to assign Domain to Knative Service


kubectl patch configmap config-domain --namespace knative-serving --patch \

  '{"data": {"example.com": null, "35.225.xxx.216.xip.io": ""}}'



본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

도커 볼륨

클라우드 컴퓨팅 & NoSQL/도커 & 쿠버네티스 | 2019. 11. 10. 21:38 | Posted by 조대협

도커 볼륨에 대한 메모


도커 컨테이너에서 파일을 저장하게 되면 디폴트로는 도커 컨테이너 Writable 레이어에 저장된다. 컨테이너 레이어에 저장이 되기 때문에, 영속적이지 못하고 컨테이너가 내려가게 되면 지워지는 임시 저장소 이다. 


컨테이너의 디스크를 컨테이너가 내려가더라도 영속적으로 저장하고 관리할 수 있는데, 이를 볼륨(Volume)이라고 한다.


%docker create volume {볼륨 이름} 

명령어를 이용해서 생성이 가능하다.

생성된 볼륨들은


% docker volume ls 

명령으로 확인이 가능하다

볼륨에 대한 상세 설정을 보려면 


%docker volume inspect {볼륨 이름}

을 사용하면 된다. 

docker volume inspect myvol

[

    {

        "CreatedAt": "2019-11-10T21:28:26+09:00",

        "Driver": "local",

        "Labels": {},

        "Mountpoint": "/var/lib/docker/volumes/myvol/_data",

        "Name": "myvol",

        "Options": {},

        "Scope": "local"

    }

]


위의 예제를 보면 생성된 볼륨의 내용을 볼 수 있는데, 로컬(호스트머신)의 어느 디렉토리에 볼륨이 저장되는지 확인할 수 있다. 위의 예제에서는 /var/lib/docker/volumes/myvol/_data 에 저장이 된다.
생성된 볼륨을 컨테이너의 파일 시스템에 마운트 시키는 방법은 다음과 같다.
$ docker service create \
     --mount 'type=volume,src=<VOLUME-NAME>,dst=<CONTAINER-PATH>,volume-driver=local,volume-opt=type=nfs,volume-opt=device=<nfs-server>:<nfs-path>,"volume-opt=o=addr=<nfs-address>,vers=4,soft,timeo=180,bg,tcp,rw"'
    --name myservice \
    <IMAGE>

src에 생성한 볼륨 이름을 dst에는 이 볼륨을 마운트 시킬 컨테이너 내부의 디렉토리를 지정하면 된다. 

Bind Mount
볼륨의 경우에는 도커 컨테이너에서만 그 파일을 내용을 볼 수 있고, 다른 컨테이너나 또는 호스트에서는 그 파일(디렉토리)의 내용을 볼 수 없다. 호스트나 다른 컨테이너에서도 접근할 수 있는 볼륨이 있는데, 이를 Bind mount라고 한다.


<그림. 도커 컨테이너 디스크 볼륨 종류와 개념 >


볼륨 생성 방법 자체는 동일하나 도커 컨테이너에 마운트 할때 Type을 "type=bind" 라고 



$ docker run -d \
  -it \
  --name devtest \
  --mount type=bind,source="$(pwd)"/target,target=/app,readonly \
  nginx:latest


tmpfs


볼륨 종류중에는 tmpfs라는 타입이 있는데, 일반 볼륨과는 다르게 호스트의 디스크 공간을 사용하는 것이 아니라 내용을 메모리에 저장하는 일종의 램 디스크라고 보면 된다.


storagedriver

마지막으로, 호스트의 디스크 이외의 다른 디스크, 예를 들어 NFS, iSCSI 등을 사용할 수 있는데, 이는 이 디스크 타입을 접근하기 위한 storagedriver를 사용해야 한다. 



참고 자료 & 이미지 예제 출처 : https://docs.docker.com/storage/https://docs.docker.com/storage/bind-mounts/

본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

KNative 를 보던중에, Autoscaling 처리를 어떻게 하는지 확인해보니,

기본은 Knative instance (한 Pod 겠지) 당 처리할 수 있는 concurrent request 수를 정해놓고, 이를 넘을 경우에 auto scaling 하는 방식이다. CPU가 아니라 connection 수를 통해서 한다. 

containerConcurrency limits the amount of concurrent requests are allowed into the application at a given time (hard limit), and is configured in the revision template.

스케일링 설정은


spec:
  template:
    metadata:
      autoscaling.knative.dev/minScale: "2"
      autoscaling.knative.dev/maxScale: "10"

min, max 값을 지정하는데, min 이 0 이면 콜드 스타트가 발생할 수 있기 때문에, 0 보다는 큰 수를 주는 것이 좋다. 


디폴트가 이 concurrent connection 수를 이용하는 방식인데, CPU 베이스도 가능하다.

spec:
  template:
    metadata:
      autoscaling.knative.dev/metric: concurrency
      autoscaling.knative.dev/class: hpa.autoscaling.knative.dev

위의 metric 모드를 사용하게 되면, concurrency 모드를 사용하게 되고, class 모드를 사용하게되면, HPA (Horizontal Pod Autoscaler)를 사용하게 된다. 


본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요


1. 클러스터는 Private IP 모드로 생성

이렇게 되면, Node는 External IP를 가지지 못한다. 즉 외부 접근을 막을 수 있다.

  • In bound : Pod로 들어오는 트래픽은 Node에  External IP가 없더라도, Service를 통해서 들어올 수 있다.
  • out bound : Cloud NAT를 설정하면 된다.
2. Master Node에 대한 접근 제안
Master authorized network 를 설정한후, authorized network에 master node를 사용할 (kubectl) 대역을 지정한다.


본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

효율적인 도커 이미지 만들기

#2 도커 레이어 캐슁을 통한 빌드/배포 속도 높이기

조대협 (http://bcho.tistory.com)


도커는 이미지 단위로 빌드를 하고 배포를 하지만, 도커의 이미지는 여러개의 레이어로 되어 있다. 아래와 같은 자바 애플리케이셔을 패키징한 도커 컨테이너 이미지가 있다고 하자

FROM openjdk:8-jre-alpine

ARG ./target/hellospring-0.0.1-SNAPSHOT.jar

COPY ${JAR_FILE} app.jar

ENTRYPOINT ["java","-jar","/app.jar"]


이 이미지가 어떤 레이어로 구성되어 있는지를 보려면 %docker history {컨테이너 이미지명} 을 실행하면 이미지의 레이어를 볼 수 있는데,   각각의 명령항에 따라서 레이어가 생성된것을 볼 수 있다. 



그리고 각각의 크기를 확인할 수 있다. 위의 history를 보면, 




  • 맨 아래 5.53M가 알파인 리눅스의 베이스 이미지

  • 그리고 위에서 4번째 79.4M가 JRE 설치

  • 위에서 2번째가 33.8M로, 애플리케이션 파일 Jar을 복사한 내용

으로 확인할 수 있다. 계층은 여러개이지만, 주로 용량을 많이 사용하는 이미지는 이 3개의 계층임을 확인할 수 있다.


이 컨테이너에서 애플리케이션을 다시 컴파일 하고 패키징해서 push를 해보면 아래와 같이 33.82M에 해당하는 애플리케이션 Jar 만을 복사하고 나머지는 “Layer already exist”와 함께 별도로 레이어를 푸쉬하지 않는 것을 확인할 수 있다. 


도커 컨테이너는 효과적인 배포를 위해서 pull/push 시에, 레이어별로 캐슁을 해서, 변경이 없는 레이어에 대해서는 다시 pull/push를 하지 않는다

자바 애플리케이션을 여러개의 레이어로 나눈 경우

이 레이어별 캐슁 기능을 잘 활용하면, 애플리케이션 컨테이너의 push/pull 시간을 많이 단축시킬 수 있다. 첫번째 push/pull은 전체 이미지를 올려야하기 때문에 시간 차이는 없겠지만, 그 후 애플리케이션만을 업데이트할 경우에는 애플리케이션에 관련된 파일만 실제로 복사되도록하고, 나머지 레이어는 캐슁된 이미지를 사용하도록 하는 방법이다.


Springboot와 같은 자바 애플리케이션은 애플리케이션 파일은 /classes에 저장되지만, 나머지 참조하는 여러 jar 파일들이 있다. 이러한 jar 파일들은 변경이 없기 때문에, 다시 재배포할 필요가 없기 때문에 캐슁을 하도록 하는 것이 좋다.


그러나 앞의 예제에서는 이 모든 라이브러리 jar 파일들을 하나의 app.jar 에 묶어서 복사하는 구조이기 때문에, 라이브러리 jar 파일만을 별도로 캐슁할 수 없다. 

그래서, 아래와 같이 애플리케이션 jar 파일을 푼 다음에, 각각의 디렉토리를 별도로 복사하는 방법을 사용한다. mvn package 에 의해서 생성된 jar 파일을 target/depdency 라는 디렉토리에 풀고, 각 디렉토리를 Dockerfile에서 각각 복사하도록 설정하였다. 


FROM openjdk:8-jre-alpine

ARG DEPENDENCY=target/dependency

COPY ${DEPENDENCY}/BOOT-INF/lib /app/lib

COPY ${DEPENDENCY}/META-INF /app/META-INF

COPY ${DEPENDENCY}/BOOT-INF/classes /app

COPY ${DEPENDENCY}/org /org


ENTRYPOINT ["java","-cp","app:app/classes/*","com.terry.HellospringApplication"]


이렇게 하게 되면, 사용자가 작성한 코드는 /classes 에 컴파일 된 상태로 저장되고, 나머지 라이브러리들은 /BOOT-INF/lib  등의 디렉토리에 저장된다. 이를 각각 Dockerfile에서 COPY 명령으로 복사하게 되면 별도의 레이어로 생성된다. 

아래는 위의 Dockerfile을 이용해서 빌드한 이미지의 레이어이다. 



앞의 예제의 경우 애플리케이션 jar 파일이 33.82M의 단일 레이어로 생성되었지만, 이 컨테이너는 176k,1.34k,1.84k,16.7M  4개의 레이어로 생성된것을 확인할 수 있다. 




이중에서 1.84k,16.7M 레이어는 Springboot 라이브러리이기 (jar파일) 때문에 변경이 없다. 그래서 캐슁이 가능한데, 


아래는 이 컨테이너를 한번 등록해놓고, 그 다음 애플리케이션 코드를 변경해서 새로 빌드하고 푸슁하는 과정이다. 


보는 것과 같이 위의 2 레이어만 새롭게 푸슁되는 것을 확인할 수 있다. 

이렇게 하면, 아래 OS 레이어, JRE, 그리고 Spring boot의 jar 라이브러리들은 모두 캐슁되고, 배포시에는 실제로 애플리케이션 class 파일만 전송되게 되기 때문에 배포 시간을 많이 단축할 수 있다.


이때 주의 할점은 기존 디렉토리에

BOOT-INF/classes

BOOT-INF/lib

META/lib

org


이런 디렉토리들이 있는데, mvn으로 새롭게 jar를 빌드한후 target/dependecy 파일에 전체 파일을 풀어버리게 되면 4개의 디렉토리가 모두 업데이트가 된다. BOOT-INF/lib,META/lib,org 디렉토리의 실제 파일 내용이 변경이 되지 않았다 하더라도, 새로운 파일로 업데이트하였기 때문에, 파일의 해쉬값이 변경되게 되고, Docker 는 빌드시에, 이 디렉토리가 변경이 되었다고 판단하고 기존의 캐슁된 레이어를 재활용하지 않고 새롭게 레이어를 생성해서 push 하기 때문에, 실제 캐쉬 효과를 볼 수 없다. 

그래서 빌드 과정에서 기존에 변경되지 않은 파일과 디렉토리는 건들지 않고, 변경된 파일만 업데이트 하도록 빌드를 구성해야 한다. 


여기서는 자바 애플리케이션을 기준으로 설명하였지만, Javascript나, 이미지와 같은 정적 파일이 있거나 라이브러리나 드라이브 설치등의 중복되는 부분이 많은 애플리케이션의 경우에는 같은 원리로 각각 레이어를 나눠 놓으면, 캐슁을 통한 push/pull 속도 절약의 효과를 볼 수 있다.


예제 파일은 스프링부트 홈페이지를 참고하였습니다. :)

본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

효율적인 도커 이미지 만들기

#1 작은 도커 이미지 만들기

조대협 (http://bcho.tistory.com)


일반적으로 도커를 이용해서 자바 애플리케이션 컨테이너를 빌드하면 보통 사이즈가 500~700M 로 배우 큰 이미지가 생성된다. 이는 Ubuntu와 같은 일반 OS 이미지 위에, JDK/JRE를 설치하기 때문인데, 실제로 자바 애플리케이션만을 실행할때는 기타 툴들 (ftp,telnet, 기타 시스템 데몬)이 필요하지 않다.


도커 이미지 사이즈는 빌드와 배포 시간에 많은 영향을 주고, 쿠버네티스와 같은 컨테이너 스케쥴링 솔루션의 경우 도커 이미지가 디스크 공간을 잡아 먹기 때문에, 작은 컨테이너가 여러모로 이점이 많다. 

작은 도커 이미지 만들기

alpine linux는 경량화를 추구하면서 보안을 강화한 이미지로 꼭 필요한 라이브러리와 시스템 데몬이 포함되어 있기 때문에 일반적인 OS이미지에 비해서 그 사이즈가 매우작다.



<그림. 이미지 사이즈별 비교> 

Java alpine 이미지

alpine linux를 기본으로 해서, 애플리케이션 구동을 위한 이미지들이 이미 많이 있는데, java의 경우 openjdk 기반의 alpine 이미지가 있다. 이미지 명은 openjdk:<자바 버전> 식으로 되고, 만약 java-8인 경우 openjdk:8 식으로 정의된다. alpine 리눅스용 openjdk 이미지는 openjdk:<자바버전>-alpine 이 된다. 


아래는 openjdk:8과, openjdk:8-alpine 이미지로 만든 컨테이너의 사이즈 비교이다. 간단한 Hello World Spring boot jar 파일 (17M정도)를 포함하였다. 



사이즈는 openjdk:8 이미지가 552M, openjdk:8-alpine은 139M가 나오는 것을 확인할 수 있다.


JDK보다는 JRE

흔히들 하는 실수중의 하나가 자바 런타임용 컨테이너를 만들때, 컴파일러가 포함된 JDK 환경을 사용한다는 것이다. 보통 자바 런타임은 JDK 없이 JRE 만 있어도 충분하다. 아래는 JRE 8 Alpine 리눅스 이미지를 이용해서 만든 컨테이너 이다.  베이스 이미지 명은 openjdk:<자바 버전>-jre-alpine 을 사용한다. 




OpenJDK 8-alpine은 139M, OpenJDK 8 JRE alpine은 119M가 되는 것을 확인할 수 있다. (20M정도 더 적다)

그러면 항상 OpenJDK에 대한 alpine JRE 이미지를 사용할 수 있는가? 답은 아니다. https://hub.docker.com/_/openjdk?tab=tags 에 들어가면 공식적으로 배포되어 있는 이미지를 확인할 수 있는다. JDK 버전에 따라서 alpine 리눅스를 안정적으로 지원하지 않을 경우에는 해당 이미지가 제공되지 않고, 다른 Linux를 사용하기 때문에, 이미지 사이즈가 200M가 넘는다. 이럴 경우에는 대안으로 Docker slim 이미지를 사용하면 된다. 


그러면 이러한 이미지들은 믿을만 한가? 도커 컨테이너 리파지토리인 hub.docker.com에서 openjdk를 찾아보면 다음과 같이 “Docker Official Images” 라는 마크가 나온다. 


이 이미지는 도커에서 관리하는 이미지로, 도커환경에 최적화 되어 있고, 또한 보안 위협에 대한 내용을 스캔해서 안전하게 제거되는 이미지이다. 

“Each of the images in the Official Images is scanned for vulnerabilities. The results of these security scans provide valuable information about which images contain security vulnerabilities, and allow you to choose images that align with your security standards.”

출처 : https://docs.docker.com/docker-hub/official_images/


결론적으로 이야기 하자면, 도커 허브에서 제공되는 Official 이미지를 사용하되, alpine 리눅스 기반으로 되어 있는 이미지를 사용하는 것이 가장 좋다.

본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

VM 수준의 보안을 제공하는 gVisor

조대협 (http://bcho.tistory.com)


Docker와 같은 일반적인 컨테이너 모델의 문제점은 Host Kernel을 공유하기 때문에, privilege escalation을 통해서 Host Kernel 을 접근해서 전체 시스템을 장악할 수 있다는 문제점이 있다. privilege escalation을 SeLinux나 컨테이너 정책으로 막는다고 하더라도, 버그등으로 인해서 Host Kernel 로의 접근을 허용할 수 있는 잠재적인 보안 위협이 있다.

컨테이너에 비해서 VM은 하드웨어 계층 부터 가상화를 해서, 전체를 Isolation 시키기 때문에, 보안적으로는 상대적으로 우세하지만, 전체적으로 무겁다는 단점을 가지고 있다.

이런 문제를 해결하기 위해서 VM과 컨테이너의 장점을 조합해서 만든 것이 gVisor 라는 오픈소스이다.


기본적으로 Host Kernel 위에서 KVM을 통해서 Kernel 을 Emulation한다. VM처럼 하드웨어 전체를 Emulate 하는 것이 아니라, Emulated 된 커널을 올릴 수 있도록 하고, 이 커널과 컨테이너는 User space에서 실행된다.

일반적인 컨테이너의 경우 컨테이너는 User space에서 실행되지만, system call을 통해서 Kernel space로 접근이 가능한데, gVisor의 경우에는 user space에 emulated 된 커널을 올려서, system call이 발생하더라도 user space를 벗어나지 않도록 해준다. 


아래 그림은 gVisor와 K8S의 관계 개념도인데, 쿠버네티스가 컨테이너를 생성 관리 하려면 컨테이너런 타임이 있어야 하는데,  gVisor의 runtime은 runsc이다. runsc는 OCI 규격을 준수하고 있기 때문에 쿠버네티스에서 기존의 컨테이너등과 호환이 가능하게 된다.   gVisor의 컨테이너는 컨테이너와 Sentry라는 가상화된 커널로 구성되며 이는 user space에서 기동된다. 


<출처 : https://www.youtube.com/embed/TQfc8OlB2sg


이러한 구조를 통해서 VM 수준의 Isolation을 제공함으로써 높은 보안을 제공한다. 

현재 Google Kubernetes Engine (이하 GKE)에서 옵션으로 활성화가 가능하며, Pod spec에 아래 그림과 같이 runtimeClassName 을 gvisor로 정해주면 된다.


apiVersion: apps/v1

kind: Deployment

metadata:

  name: httpd

  labels:

    app: httpd

spec:

  replicas: 1

  selector:

    matchLabels:

      app: httpd

  template:

    metadata:

      labels:

        app: httpd

    spec:

      runtimeClassName: gvisor

      containers:

      - name: httpd

        image: httpd


이렇게 하면 이 Pod는 gvisor를 통해서 isolation이 된다. 일반적인 애플리케이션인 java,node.js,ruby 나 redis나 mysql과 같은 범용 애플리케이션은 잘 동작하지만


gVisor는 높은 수준의 보안을 요구 하는 애플리케이션이나 특히 대외로 서비스 되는 Multi tenant application의 경우 높은 isolation 레벨을 제공해서, 다른 Pod 들이 영향을 받지 않도록 하는데 유용하게 사용할 수 있다. 


이러한 장점은 있지만 역시 만능은 아니고 제약 사항이 분명히 있다.

  • HostPath 볼륨 사용불가

  • Istio 사용불가

  • 일부 PSP 사용불가

  • Pod나 컨테이너 레벨 모니터링 불가

  • Kernel 의 특정 보안 모듈 secomp,Apparmor,Selinux 등 사용 불가

  • GPU 등 사용불가

자세한 제약 사항은 https://cloud.google.com/kubernetes-engine/docs/how-to/sandbox-pods#limitations 문서를 참고하기 바란다. 



본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

  1. 조윤희 2019.09.24 08:22  댓글주소  수정/삭제  댓글쓰기

    GPU, TPU 지원되는 VM 이나, privilege 설정없이 TPU를 사용할수있는 docker는 없나요?

CRI & OCI


기본적으로 도커 기반의 쿠버네티스는 다음과 같은 구조로 작동을 했었다. Kubelet이 명령을 받으면, Docker runtime을 통해서 컨테이너를 생성하거나 삭제하는 것과 같은 생명 주기를 관리하는 구조를 가지고 있었다. 



그런데, Docker 이외에도 여러가지 컨테이너 기술이 나오면서 쿠버네티스에서 이런 다양한 컨테이너 런타임에 대한 지원 요건이 생기기 시작하였고, 다양한 컨테이너 런타임을 지원하기 위해서 그때 마다 Kubelet의 코드를 수정해야 하는 문제가 생겼다.


그래서, kubelet의 코드를 수정하지 않고, 다양한 컨테이너 런타임을 지원하기 위해서, kubelet과 컨테이너 런타임 사이의 인터페이스를 통일화하는 스펙이 등장하였는데, 이것이 CRI (Container Runtime Interface)이다. 컨테이너의 생성,삭제 등의 생명 주기를 관리하는 스펙으로 gRPC 기반의 API 스펙으로 되어 있고, 새로운 컨테이너 런타임은 CRI 스펙에 맞춰서 CRI 컴포넌트를 구현하면 되는 구조가 되었다. 


그래서, 컨테이너 런타임이 CRI 스펙에 맞춰서 구현이 되면, kubelet의 코드 변화 없이 새로운 컨테이너 런타임을 플러그인 구조로 추가할 수 있는 구조가 된것이다.  Docker의 경우에는 docker shim 이라는 CRI 인터페이스를 준수하는 구현체를 제공하고 있고, rkt 컨테이너의 경우는 rktlet 이라는 이름의 CRI 구현체를 제공하고 있다. 

그런데, 지원되는 컨테이너의 종류가 계속해서 늘어가고 있고, 그때마다, CRI를 다시 구현해야 하는 문제가 생김에 따라 컨테이너 런타임 자체를 표준화하고자 하는 노력이 있었는데, 그로 인해서 정해진 스펙이 OCI (Open Container Initiative) 이다. OCI 스펙을 맞춰서 구현된 컨테이너 런타임을 별도의 CRI 구현이 없이 OCI를 지원하는 CRI 구현체에 의해서 관리가 가능해진다. OCI 스펙에 따른 컨테이너 런타임을 관리하는 CRI 컴포넌트는 CRI-O 라는 컴포넌트로 구현되어 있다. 즉 OCI 스펙을 준수한다면, CRI-O를 통해서 kubelet으로 부터 명령을 받을 수 있는 구조가 된다. 



본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

쿠버네티스 Skaffold에서는 하나의 Configuration에서 Profile을 통하여, 배포 파이프라인을 여러개 만들어서 다른 환경에 배포할 수 있고,

각 환경은 kubernetesContext를 이용해서, 쿠버네티스 클러스터를 고를 수 있다. 


build:
  artifacts:
  - image: gcr.io/k8s-skaffold/skaffold-example
deploy:
  kubectl:
    manifests:
    - k8s-pod
profiles:
- name: profile1
  activation:
    - env: MAGIC_VAR=42
- name: profile2
  activation:
    - env: MAGIC_VAR=1337
    - kubeContext: minikube
      command: dev


본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요



쿠버네티스 애플리케이션을 위한 개발환경 설정하기

#2 VS Code

조대협 (http://bcho.tistory.com)

마이크로소프트 VS Code

다음 소개할 도구는 마이크로소프트사의 VS Code 이다. 자바 언어가 아닌 Python,node.js 등의 개발에는 VS Code 가 많이 사용되는 데, 특히 쿠버네티스 관련 플러그인들이 많아서 쿠버네티스 연동에 있어서는 IntelliJ보다 훨씬 좋은 기능을 제공한다.


설치하기

VS Code에, 쿠버네티스 개발환경을 설치해보자, 설치전에는 kubectl, docker, skaffold 가 미리 설치되어 있어야 한다. 

다음 웹 브라우져에서 이 링크(vscode:extension/GoogleCloudTools.cloudcode)를 실행하면, VS 코드에서 아래와 같이 Cloud Code 설치 화면이 나온다.



여기서 우측 화면의 Cloud Code  부분에서 인스톨 버튼을 누르면, 플러그인이 설치 된다.

설치가 완료되면 VS Code 하단에 다음과 같이 Cloud Code 아이콘이 생성된다. 

테스트 애플리케이션 만들기

플러그인 설치가 끝났으면, 테스트 애플리케이션을 하나 만들어 보자

VS Code 하단의 Cloud Code 버튼을 누르면, 아래 그림과 같이 VS Code 상단에 Text Box로, 메뉴를 선택할 수 있는 창이 나온다. 여기서 New Application을 선택한다




 그중에서  아래 그림과 같이 node.js:Hello world를 선택한다.




생성된 프로젝트의 구조는 아래 그림과 같다.



  • /kubenetes-manifests 디렉토리에는 쿠버네티스 자원에 대한 정의가 yaml 파일로 되어 있다. 이 예제에서는 service와 deployment  두 자원이 정의 된다.

  • /Dockerfile 에는 도커 이미지를 빌딩하기 위한 설정이 되어 있가

  • /skaffold.yaml 은 컨테이너 이미지를 빌드 배포하기 위한 설정이 들어 있다. 


애플리케이션 배포하기

VS Code 아래 Cloud Code 메뉴에서 Deploy application을 선택하면, 이 node.js 애플리케이션을 컨테이너로 패키징해서 Skaffold 를 통해서 쿠버네티스 클러스터에 배포한다. 


이때 몇가지를 물어보는데, 

  • build : “default”를 선택한다. 이 옵션은 컨테이너를 어디서 빌드 할것인지에 대한 옵션인데, “default”는 로컬 환경에서 docker를 이용해서 컨테이너를 만드는 옵션이고, 필요하다면, 구글 클라우드의 Cloud Build를 사용할 수 도 있다. Cloud Build는 로컬에서 빌드를 하는 것이 아니라, 빌드에 필요한 모든 파일들을 Cloud Build 클라이언트가 tar로 묶어서, 구글 클라우드의 Cloud Build로 보내서 빌드하는 방식인데, 만약에 빌드 태스크가 많은 빌드 서버라면 (Jenkins와 같은), 하나의 서버에서 여러 빌드를 할 수 없기 때문에 분산 빌드가 필요한데, Cloud Build를 사용하면, 클라우드에서 빌드를 건건이 해주기 때문에 빌드 머신의 리소스를 사용하지 않고, 여러 빌드를 동시에 진행할 수 있는 장점이 있다. 

  • 다음은 쿠버네티스 클러스터를 고르게 되는데, 이미 kubectl 이 깔려 있다면, 현재 연결되어 있는 클러스터들 중 하나를 선택할 수 있다. 


다음 그림은 설정이 끝난 후에, node.js 애플리케이션을 도커로 패키징해서 skaffold를 통해 쿠버네티스 클러스터로 배포하는 과정이다. 




빌드 및 배포가 완료되면, 아래 그림과 같이 쿠버네티스 service 의 end point URL이 출력된다.


해당 URL을 웹 브라우져에서 열어보면 아래 그림과 같이 애플리케이션을 동작하는 결과를 확인할 수 있다.


로그 및 쿠버네티스 자원 보기

VS Code에는 Kubernetes Explorer 라는 기능이 같이 설치 되는데, 이 기능은 현재 개발환경에 연결되어 있는 쿠버네티스 클러스터와 그 자원 (namespace, deployment, pods 등)을 보여준다. 

아래 그림은 개발환경에서 쿠버네티스 클러스터의 자원들을 보는 화면이다. 



앞에서 배포한 애플리케이션의 로그를 보고 싶으면 이 화면에서, 배포된 Pod의 오른쪽 버튼으로 클릭하면 “Stream Log”라는 메뉴가 나온데, 이 메뉴를 클릭하면 로그를 볼 수 있다 

위의 예제에서는 node-hello-world-649.. Pod를 선택하였다. 

아래는 실제로 출력되는 로그 결과이다. 


컨테이너로 SSH 접속하기

VS Code는 IntelliJ에 비해서 쿠버네티스에 관련된 여러가지 부가 기능을 제공하는데, 유용한 기능중 하나가 Pod의 컨테이너로 직접 SSH로 접속할 수 있는 기능이 있다.


위의 그림과 같이 Kubernetes Cluster Explorer 에서  Pod 아래 SSH로 로그인하고자 하는 컨테이너를 선택한 후에, 오른쪽 버튼을 누르고, Get Terminal 이라는 메뉴를 실행하면 아래 그림과 같이 VS Code 안에서 바로 그 컨테이너로 SSH 터미널이 열린다. 


쿠버네티스 자원 설정 보기

앞에서 쿠버네티스 클러스터들의 자원 목록을 볼 수 있었다. 다음으로 유용한 기능중의 하나는 각 자원에 대한 설정 정보를 볼 수 있는 기능이 있는데, 쿠버네티스 리소스를 선택한 후 Edit in YAML을 선택하면 해당 쿠버네티스 리소스의 YAML 파일을 볼 수 있다. 


디버깅

마지막은 애플리케이션 디버깅 기능인데, IntelliJ와 마찬가지로 쿠버네티스 클러스터로 배포된 애플리케이션에 대해서 온라인 디버깅이 가능하다. 

우측에 디버그 아이콘

을 클릭하면 디버그 뷰로 바뀌는데, 

코드에 브레이크 포인트 찝어 놓고, 디버그 모드에서 디버깅 시작 버튼


을 누르면 디버깅 모드로 변경되는데, 이렇게 해놓고, 웹 사이트를 실행하면, 아래 그림과 같이 브레이크 포인트에서 멈추고, 디버깅을 할 수 있다.




디버그 종료는 상단 디버그 툴 창


우측 붉은 버튼을 누르면 종료된다.


지금까지 간단하게, IntelliJ와 VSCode IDE에서 쿠버네티스를 위한 개발 환경 설정 방법에 대해서 알아보았다. 쿠버네티스 자체에 대한 설정과 운영/모니터링도 중요하지만, 쿠버네티스에 잘 적응하기 위해서는 개발자들이 손쉽게 개발환경에 접근할 수 있는 환경이 되어야 하기 때문에, 조직의 개발팀에 맞는 개발 환경과 프로세스를 잘 정리하기를 권장한다.

본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요