{{ post.content | strip_html | truncatewords: 15 }}
13 | {{post.date | date: '%Y, %b %d'}} — 14 | {% capture words %}{{ post.content | number_of_words }}{% endcapture %}{% unless words contains "-" %}{{ words | plus: 250 | divided_by: 250 | append: " minute read" }}{% endunless %} 15 |by 최태일(taeil.choi@sk.com)
9 | 10 | ## Update on 2019.07.30 [새로운 블로그]로 이전하였습니다 11 | 12 | ## Overview 13 | 이번 포스팅에서는 Kubernetes 환경에서 모니터링 tool로 많이 사용되고 있는 Prometheus를 사용하여 TACO 서비스에 이벤트 발생시 Alerting해주는 부분에 대해 살펴보겠습니다. 실제 TACO에서 사용 중인 Event alerting 내용을 보여드리기보다는, 독자들의 이해를 돕기 위해 Metric 수집부터 실제 Alert notification까지의 기본적인 Flow를 Tutorial 형식으로 풀어나가려고 합니다. 14 | 15 | 16 | 17 | ## Prometheus 개요 18 | Prometheus는 시계열 데이터 모니터링을 수행하는 오픈소스 모니터링 솔루션입니다. 19 | 음악 유통 플랫폼 회사인 SoundCloud라는 곳에서 시작한 프로젝트이고, 2012년 이후 여러회사에서 참여해서 발전하다가 2016년도에 Cloud Native Computing Foundation에 합류하였습니다. Kubernetes에 이은 두번째 공식 프로젝트이죠. 20 | 21 | Go 언어로 개발되었고, Apache License v2.0 을 따르며, 다음과 같은 특징을 가집니다. 22 | 23 | - Multi-demensional data model 24 | - 데이터는 초기 버전에서는 key-value 형태의 NoSQL DB인 LevelDB에 저장하였으나 v2.0부터는 자체 TSDB를 개발하여 사용 25 | - 유연하고 사용하기 쉬운 query language 26 | - http 프로토콜을 사용한 server-side pull 방식의 시계열데이터 수집 27 | - Service Discovery나 Static 모두 사용가능한 구조 28 | 29 | Prometheus Architecture는 다음과 같습니다. 30 | 31 |  32 | 33 | 기본적으로 exporter 들로부터 pull 방식으로 metric을 가져오며 Service Discovery 기능을 통해 Kubernetes 클러스터 등 외부 Resource들에 대한 metric도 가져오게 됩니다. 발생한 Alert은 alertmanager에게 전달하여 email이나 slack 등의 receiver로 alert 메세지를 발송합니다. 34 | 35 | 36 | 37 | ## Step by Step Guide for Alerting 38 | 39 | ### prometheus 및 node-exporter 실행 40 | 41 | 아래 가이드에 따라 prometheus 및 node-exporter를 실행합니다. 42 | (이 가이드에서는 두 프로세스 모두 system service로 등록하였지만, 단순히 테스트 목적이라면 그 과정은 생략하고 command를 직접 수행해도 무방합니다.) 43 | 44 |by 이재상(jaesang_lee@sk.com)
9 | 10 | ## Update on 2019.07.30 [새로운 블로그]로 이전하였습니다 11 | 12 | ## Overview 13 | 보통 서비스 및 소프트웨어를 개발하는 경우, 최초에 기능 검증을 하거나 빠르게 개발하기 위해 하나의 서버에 모든 기능을 구현합니다. 그러나 서비스 규모가 증가한다던가 혹은 서비스 요청이 무척 많아질 것을 대비하려면 서버 한대로는 원하는 것을 이룰 수 없겠죠. 이에 서비스를 분산 배포하기 시작합니다. 예를 들어 소규모 서비스일 때는 DB서버 1대만 구축하지만, 서비스 리퀘스트가 증가한다면 복수의 DB서버로 클러스터링을 구성하는 식입니다. 이렇게 증가되는 서비스는 DB뿐만이 아닙니다. TACO의 경우 OpenStack 서비스별 API, Scheduler가 다수 실행되며 RabbitMQ, Ingress, Etcd, Open vSwitch, Memcached 등 수 많은 서비스가 분산 배포됩니다. 14 | 15 | 이런 서비스를 개발하면서 그에 대한 안정성 테스트를 생각하게 됩니다. 분산 서비스를 하는 이유는 속도 개선도 있지만 서버 한대가 이상이 생겨도 나머지 서버들이 서비스를 안전하게 동작시키기 위함입니다. 때문에 전통적인 기능, 성능 테스트뿐 아니라 장애 테스트를 추가하게됩니다. 16 | 17 | 장애 테스트를 하려면 다음을 규정해야 합니다. 18 | 19 | 1. 정상 상태에 대한 규정 - 정상이라고 판단하기 위해 동작해야 하는 기능 리스트 20 | 2. 장애 발생 변수에 대한 규정 - 서비스의 구성요소(하드웨어, 네트워크, 스토리지 장애 및 OS 장애 등등) 21 | 22 | 위 두가지를 정의했다면 이제 정상 상태의 서비스에 장애를 발생시키면서 서비스가 정상 작동하는지 검증해야합니다. 이는 실제로 일어날 수 있는 상황들을 가정하기 때문에 운영을 하기 위해 꼭 필요한 테스트입니다. 서비스 운영 시 발생하는 장애 요인을 미리 제거하는 이러한 활동을 카오스 엔지니어링[1](#f1)이라고 합니다. 23 | 24 | 25 |  26 | [](https://creativecommons.org/licenses/by-nc-nd/4.0/) 27 | 28 | 위 그림은 내부에 구축한 CI/CD Pipeline에 대한 구성도입니다. OpenStack Container 빌드 혹은 Helm Chart 빌드 때마다 그림에 표시된 "Integration Test"단계에서 아래에서 설명할 장애테스트를 수행하여 TACO 서비스의 안정성을 검증하고 있습니다. 이 글에서는 TACO에서 사용하는 장애 발생 툴인 Cookiemonster와 장애 테스트에 대해 설명합니다. TACO CI/CD에 대해서는 따로 포스트를 작성할 예정입니다. 29 | 30 | ## Kubernetes 구조 31 | TACO는 Kubernetes위에 구축된 OpenStack 서비스로 TACO를 알기 위해서는 Kubernetes의 이해가 필요합니다. Kubernetes의 대한 내용은 [이전 글]({{ site.baseurl }}{{ post.url }}/Taco/#kubernetes)을 참고하시기 바랍니다. 32 | 33 | ## 장애 발생 툴 34 | Kubernetes환경에서 사용하는 장애 발생 툴은 여러가지가 있습니다. 대부분 넷플릭스의 카오스몽키의 영감을 갖고 만들어졌으며, 각자 Kubernetes 환경에 대한 장애를 발생시킵니다. 35 | 36 | - kube-monkey 37 | - chaoskube 38 | - powerfulseal 39 | 40 | | Tools | Repo | 실행방법 | 41 | | ------------- |------------------------------------------ | ----------------- | 42 | | kube-monkey | https://github.com/asobti/kube-monkey | Install template | 43 | | chaoskube | https://github.com/linki/chaoskube | Command Line | 44 | | powerfulseal | https://github.com/bloomberg/powerfulseal | Command Line | 45 | 46 | ## Cookiemonster 47 | Cookiemonster는 SKT에서 개발한 Apache 2.0 라이센스의 오픈소스 프로젝트로 TACO의 CI/CD에서 사용하고 있는 Kubernetes용 장애발생툴입니다. 또한, 구축된 TACO에 대한 장애테스트 용도로도 사용할 수 있습니다. 48 | - Project Code:by 임성일(si.im@sk.com)
8 | 9 | ## Update on 2019.07.30 [새로운 블로그]로 이전하였습니다 10 | 11 | ## Overview 12 | 13 | 실행 중인 애플리케이션이나 시스템의 내부 상황을 파악하는데 일반적으로 로그를 사용합니다. 특히, 로그는 문제를 디버깅하고 작업을 모니터링하는 데 유용합니다. 일반적인 응용 소프트웨어들은 다양한 로깅 메커니즘을 제공하고 있으며 TACO의 기반 소프트웨어인 오픈소스들도 각각의 로깅 기능을 제공합니다. TACO의 기반 컨테이너 엔진인 docker-engine의 경우 간단하면서 일반적으로 사용하는 logging 방식인 표준출력과 표준에러를 사용하는 로깅 기능을 제공하고 있습니다. 차상위 시스템인 kubernetes 또한 그 나름의 로깅 기능을 제공합니다. 14 | 15 | 하지만 docker나 kubernetes에서 제공하는 로깅 기능으로는 TACO의 상황을 효율적으로 감시할 수 없습니다. TACO의 로그는 그 구성요소인 pod나 컨테이너등의 문제로 인해 재기동 되거나 삭제 되었을때에도 관련 로그를 유지하고 있어야 하며 이를 위해 별도의 저장소와 유지주기 등을 관리해야 합니다. 이러한 기능을 수행하는 것을 TACO Logging 입니다. 16 | 17 | 본 포스트에서는 TACO Logging의 구조와 동작방식을 설명하여 독자들의 이해도를 높히고자 합니다. 또한, 사용자의 요구사항을 반영하는 변경을 구축에 반영하는 예시를 제시하여 이를 참조하여 자신만의 구축형상을 수정할 수 있도록 하겠습니다. 18 | 19 | ### Logging in docker 20 | 21 | TACO의 기반 컨테이너 엔진인 docker는 자체의 로깅 기능을 제공하고 있습니다. 로깅 드라이버(logging driver)를 사용하여 표준출력과 표준에러에 대한 처리를 수행합니다. 기본설정에서 docker는 표준출력과 표준에러애서 발생하는 모든 로그를 json 형태로 변환하여 각 컨테이너별 로그파일로 저장합니다. 로깅 드라이버는 컨테이너마다 지정할 수 있으며 이에 대한 설정등은 다음의 페이지를 참조할 수 있습니다. 22 | * 로깅 드라이버 설정 (https://docs.docker.com/config/containers/logging/configure/) 23 | * 드라이버에 plugin 적용 (https://docs.docker.com/config/containers/logging/plugins/) 24 | * output 조절하기 (https://docs.docker.com/config/containers/logging/log_tags/) 25 | 26 | ### Logging in kubernetes 27 | 28 | Kubernetes에서는 App과 system의 log를 제공하여 클러스터 내부를 사용자가 이해할수 있도록 돕습니다. 간단하게 다음과 같은 명령으로 클러스터내 존재하는 POD (컨테이너)에 대한 로그를 얻어올 수 있습니다. 29 | 30 | ```bash 31 | kubectl logs -n [namespace] [pod_name] 32 | ``` 33 | ```bash 34 | taco@master:~$ kubectl logs elasticsearch-data-2 35 | + COMMAND=start 36 | + start 37 | + ulimit -l unlimited 38 | + exec /docker-entrypoint.sh elasticsearch 39 | [2018-04-13T05:07:27,992][INFO ][o.e.n.Node ] [elasticsearch-data-2] initializing ... 40 | [2018-04-13T05:07:28,193][INFO ][o.e.e.NodeEnvironment ] [elasticsearch-data-2] using [1] data paths, mounts [[/usr/share/elasticsearch/data (/dev/rbd4)]], net usable_space [933.2gb], net total_space [984.1gb], spins? [no], types [ext4] 41 | [2018-04-13T05:07:28,194][INFO ][o.e.e.NodeEnvironment ] [elasticsearch-data-2] heap size [1.9gb], compressed ordinary object pointers [true] 42 | [2018-04-13T05:07:28,298][INFO ][o.e.n.Node ] [elasticsearch-data-2] node name [elasticsearch-data-2], node ID [-B45XC7NR5qqvab3zfqgdg] 43 | [2018-04-13T05:07:28,298][INFO ][o.e.n.Node ] [elasticsearch-data-2] version[5.6.4], pid[41], build[8bbedf5/2017-10-31T18:55:38.105Z], OS[Linux/4.4.0-116-generic/amd64], JVM[Oracle Corporation/OpenJDK 64-Bit Server VM/1.8.0_151/25.151-b12] 44 | [2018-04-13T05:07:28,298][INFO ][o.e.n.Node ] [elasticsearch-data-2] JVM arguments [-Xms2g, -Xmx2g, -XX:+UseConcMarkSweepGC, -XX:CMSInitiatingOccupancyFraction=75, -XX:+UseCMSInitiatingOccupancyOnly, -XX:+AlwaysPreTouch, -Xss1m, -Djava.awt.headless=true, -Dfile.encoding=UTF-8, -Djna.nosys=true, -Djdk.io.permissionsUseCanonicalPath=true, -Dio.netty.noUnsafe=true, -Dio.netty.noKeySetOptimization=true, -Dio.netty.recycler.maxCapacityPerThread=0, -Dlog4j.shutdownHookEnabled=false, -Dlog4j2.disable.jmx=true, -Dlog4j.skipJansi=true, -XX:+HeapDumpOnOutOfMemoryError, -Xms2g, -Xmx2g, -Des.path.home=/usr/share/elasticsearch] 45 | [2018-04-13T05:07:29,169][INFO ][o.e.p.PluginsService ] [elasticsearch-data-2] loaded module [aggs-matrix-stats] 46 | [2018-04-13T05:07:29,170][INFO ][o.e.p.PluginsService ] [elasticsearch-data-2] loaded module [ingest-common] 47 | [2018-04-13T05:07:29,170][INFO ][o.e.p.PluginsService ] [elasticsearch-data-2] loaded module [lang-expression] 48 | [2018-04-13T05:07:29,170][INFO ][o.e.p.PluginsService ] [elasticsearch-data-2] loaded module [lang-groovy] 49 | [2018-04-13T05:07:29,170][INFO ][o.e.p.PluginsService ] [elasticsearch-data-2] loaded module [lang-mustache] 50 | [2018-04-13T05:07:29,170][INFO ][o.e.p.PluginsService ] [elasticsearch-data-2] loaded module [lang-painless] 51 | [2018-04-13T05:07:29,170][INFO ][o.e.p.PluginsService ] [elasticsearch-data-2] loaded module [parent-join] 52 | [2018-04-13T05:07:29,170][INFO ][o.e.p.PluginsService ] [elasticsearch-data-2] loaded module [percolator] 53 | [2018-04-13T05:07:29,170][INFO ][o.e.p.PluginsService ] [elasticsearch-data-2] loaded module [reindex] 54 | [2018-04-13T05:07:29,170][INFO ][o.e.p.PluginsService ] [elasticsearch-data-2] loaded module [transport-netty3] 55 | [2018-04-13T05:07:29,171][INFO ][o.e.p.PluginsService ] [elasticsearch-data-2] loaded module [transport-netty4] 56 | [2018-04-13T05:07:29,171][INFO ][o.e.p.PluginsService ] [elasticsearch-data-2] no plugins loaded 57 | [2018-04-13T05:07:30,393][INFO ][o.e.d.DiscoveryModule ] [elasticsearch-data-2] using discovery type [zen] 58 | [2018-04-13T05:07:31,121][INFO ][o.e.n.Node ] [elasticsearch-data-2] initialized 59 | [2018-04-13T05:07:31,121][INFO ][o.e.n.Node ] [elasticsearch-data-2] starting ... 60 | [2018-04-13T05:07:31,274][INFO ][o.e.t.TransportService ] [elasticsearch-data-2] publish_address {172.16.119.179:9300}, bound_addresses {[::]:9300} 61 | [2018-04-13T05:07:31,283][INFO ][o.e.b.BootstrapChecks ] [elasticsearch-data-2] bound or publishing to a non-loopback or non-link-local address, enforcing bootstrap checks 62 | ``` 63 |  64 | 65 | 그림출처: https://kubernetes.io 66 | 67 | kubernetes는 노드수준에서 로그의 보존, 로테이션 기능을 제공합니다. 또한 POD의 타 노드로 이동(migraion)시 컨테이너 뿐 아니라 해당 로그를 함께 옮겨주는 기능도 수행하고 있습니다. 노드수준에서의 로깅기능만 제공하고 있을뿐 공식적으로 클러스터 수준에서 로깅기능을 제공하는 솔루션은 없습니다. 68 | ## fluent-logging (Central logging on k8s) 69 | ### Cluster logging in k8s (reference architecture) 70 | kubernetes에서는 공식적인 솔루션을 제시하지 않지만 다음과 같은 일반적인 방식을 고려할 수 있습니다. 71 | * Use a node-level logging agent that runs on every node. (**fluent-logging approach**) 72 | * Include a dedicated sidecar container for logging in an application pod. 73 | * Push logs directly to a backend from within an application. 74 | 75 | 공식 페이지에서는 아래와 같은 아키텍쳐를 제시합니다.([kubernetes logging](https://kubernetes.io/docs/concepts/cluster-administration/logging/#cluster-level-logging-architectures)) 76 | 77 | | Using a node logging agent | Streaming sidecar container | 78 | | :-------------: |:-------------:| 79 | |  |  | 80 | 81 | | Sidecar container with a logging agent | Exposing logs directly from the application | 82 | | :-------------: |:-------------:| 83 | |  | | 84 | 85 | 그림출처: https://kubernetes.io 86 | 87 | ### Architecture 88 | 앞에서 언급한 것처럼 kubernetes는 몇가지 클러스터 수준의 로깅기능을 제시하고 있습니다. 제시된 모델 중 첫번째 방식(Using a node logging agent)를 제외한 나머지 방법은 해당 애플리케이션(POD) 내부에 해당 기능을 제공해야 합니다. 이에 따라, 우리는 기존 애플리케이션의 변경없이 사용할 수 있는 logging agent를 사용하는 방법을 사용하였고 기반시스템에서 제공하는 로깅기능을 활용하여 필요한 메타정보를 추가하여 별도 저장하는 형태로 시스템을 설계했습니다. 또한 agent 설치 노드에 대한 small-footprint를 유지하도록 하면서 확장성을 확보하도록 하는 유연한 구조를 갖도록 하였습니다. 89 | 90 |  91 | 92 | * log collection: 93 | * 해당 노드에서 동작 중인 컨테이너의 로그를 수집하고 이를 aggregator에 전달 94 | * Small-footprint 유지 95 | * 각 물리노드 별로 daemonset으로 기동 96 | * fluent-bit 사용 97 | * aggregator 98 | * 수집된 로그에 필요한 전/후처리 가능하고 다양하게 확장가능 99 | * 지정한 노드에 필요한 수 만큼의 deployment로 기동 100 | * fluentd 사용 101 | * storage 102 | * 수집된 로그를 저장하고 조회기능 제공 103 | * 필요한 크기에 따라 저장/조회/정보저장용 pod 각각 조정가능 104 | * elasticsearch 사용(JVM Heap사이즈 조정 및 디스크 용량만 변경하여 최적화) 105 | * Presentation Layer 106 | * 데이터에 대한 조회 및 통계를 위한 사용자 인터페이스 제공 107 | * 정형화된 조회구조를 정의 후 대시보드 구성 108 | * kibana 사용 109 | 110 | 추가적으로 TACO Logging은 3rd-party 툴 연동이 가능합니다. 통합기(aggregator)를 통해 kafka에 데이터를 전달할 수 있도록 구현되어 있으며 외부 툴들은 kafka의 데이터를 구독하면 TACO Logging에서 수집한 로그를 실시간 활용가능합니다. 111 | 112 | --- 113 | 참고. **Agent 선택** 114 | 115 | 오픈소스 진영에는 logstash, fluentd, flume, beaver와 같이 다양한 로그수집기가 존재한다. 이들은 각각의 특징을 갖고 있으며 이에 따라 상황에 따른 장단점을 갖고 있다. 일반적인 경우에 logstash가 가장 많이 쓰이고 있으며, Hadoop 등 Big-Data 관련 솔루션의 경우 flume을 선호하는 경향이 있다. Monasca 진영의 경우 beaver를 사용하여 로그를 수집한다. 그 외에도 elasticsearch 등을 주도하고 있는 elastic.co의 filebeat 또한 고려가능하다. TACO에서는 kubernetes의 매타정보를 가장 잘 반영할 수 있고 fluent-bit으로 small-footprint를 지원하는 fluent를 수집기로 선정하여 사용하였다. 116 | 117 | Fluent 진영에서는 small-footprint 지원을 위해 기존의 로그 수집기인 fluentd와 별도로 이를 경량화한 fluent-bit이라는 로그수집기를 소개하였으며 두 수집기의 차이는 아래 표와 같다. TACO에서는 이러한 특징을 반영하여 로그 수집기로 fluent-bit을 로그 통합기(aggregator)로 fluentd를 사용하였다. 118 | 119 | | | Fluentd | Fluent Bit | 120 | | --- | --- | --- | 121 | |Scope |Containers / Servers |Containers / Servers| 122 | |Language |C & Ruby |C| 123 | |Memory |~40MB |~450KB| 124 | |Performance |High Performance |High Performance| 125 | |Dependencies |Built as a Ruby Gem, it requires a certain number of gems. |Zero dependencies, unless some special plugin requires them.| 126 | |Plugins |More than 650 plugins available |Around 30 plugins available| 127 | |License |Apache License v2.0 |Apache License v2.0| 128 | |memo |**Various plugins** |**Small foot-print**| 129 | 130 | --- 131 | 132 | --- 133 | 참고. **노드별 로그위치** 134 | 135 | docker의 경우 기본적으로 모든 컨테이너 로그를 물리서버(BareMetal)의 /var/lib/docker/containers/[Container-HASH]/[Container-HASH]-[Type].log 의 위치에 type별 로그를 저장한다. k8s에서는 이 로그를 필요한 매타데이터와 함께 link를 설정하여 각 로그파일을 관리한다. k8s의 관점에서 보면 모든 pod의 로그들을 /var/log/container/* 형태로 하나의 디렉토리 하부에 매타정보를 포함한 링크명과 함께 저장하여 관리하고 있다. TACO에서 설치하는 로그 수집기는 해당 디렉토리에서 발생하는 모든 로그를 추적하는 것으로 raw 데이터를 수집하고 필요한 매타정보를 추가하여 저장소로 전달한다. 136 | 137 | *링크로 연결된 로그파일 예시* 138 | ``` 139 | /var/log/containers/weave-scope-app-65f7f776f9-b6qkk_kube-system_app-eccff309fe566b5397faa3939cfa2773966f9a39e3bf0b3f598f45c94f80e13f.log -> /var/log/pods/8de1b0c2-062d-11e8-b54c-3ca82a1c8f58/app_0.log 140 | /var/log/pods/8de1b0c2-062d-11e8-b54c-3ca82a1c8f58/app_0.log -> /var/lib/docker/containers/eccff309fe566b5397faa3939cfa2773966f9a39e3bf0b3f598f45c94f80e13f/eccff309fe566b5397faa3939cfa2773966f9a39e3bf0b3f598f45c94f80e13f-json.log 141 | /var/lib/docker/containers/eccff309fe566b5397faa3939cfa2773966f9a39e3bf0b3f598f45c94f80e13f/eccff309fe566b5397faa3939cfa2773966f9a39e3bf0b3f598f45c94f80e13f-json.log 142 | ``` 143 | --- 144 | 145 | ### Logs in ElasticSearch (Schema) 146 | 147 | TACO에서 수집된 로그는 최종 저장소인 ElasticSearch(이하 ES)에 다양한 메타정보를 포함하여 저장됩니다. 저장되는 단위는 표준출력 혹은 표준에러에서 발생하는 로그 한줄이 하나의 도큐먼트화되어 저장됩니다. 저장된 데이터를 효율적으로 활용하기 위해서는 저장형태에 대한 규정이 필요합니다. fluent-logging은 이를 위해 ES의 대상 인덱스에 mapping (스키마)를 설정하고 있습니다. 이 값은 구축시 사용자의 요구에 따라 변경 가능합니다. 148 | 149 | 기본적으로 ES는 모든 문장을 단어단위로 분리하여 저장합니다. 추후 조회나 분류를 위해 정확한 필드의 내용을 사용해야 하는 경우 분리된(tokenized) 필드의 경우 해당 작업이 힘들거나 불가능 할 수도 있습니다. 예를들면 pod명의 경우 'weave-scope-agent-56dfr' 와 같은 값을 갖는데 기본 저장방식을 사용하면 weave, scope, agent, 56dfr 형태로 각각 분리되어 저장되고 검색도 단어 단위로 이뤄집니다. 150 | 151 | fluent-logging에서는 다음의 정보들을 활용하기 위해 분리하지 않고 키워드 형태로 저장하도록 하고 있으며 인덱스와 저장되는 데이터의 예시는 다음과 같습니다. 152 | 153 | **Mapping** 154 | ```xml 155 | "mappings" : { 156 | "fluent-logging" : { 157 | "properties" : { 158 | "kubernetes" : { 159 | "properties" : { 160 | "container_name" : { 161 | "index" : "not_analyzed", 162 | "type" : "keyword" 163 | }, 164 | "docker_id" : { 165 | "index" : "not_analyzed", 166 | "type" : "keyword" 167 | }, 168 | "host" : { 169 | "index" : "not_analyzed", 170 | "type" : "keyword" 171 | }, 172 | "labels" : { 173 | "properties" : { 174 | "app" : { 175 | "index" : "not_analyzed", 176 | "type" : "keyword" 177 | }, 178 | "application" : { 179 | "index" : "not_analyzed", 180 | "type" : "keyword" 181 | }, 182 | "component" : { 183 | "index" : "not_analyzed", 184 | "type" : "keyword" 185 | }, 186 | "release_group" : { 187 | "index" : "not_analyzed", 188 | "type" : "keyword" 189 | } 190 | } 191 | }, 192 | "namespace_name" : { 193 | "index" : "not_analyzed", 194 | "type" : "keyword" 195 | }, 196 | "pod_id" : { 197 | "index" : "not_analyzed", 198 | "type" : "keyword" 199 | }, 200 | "pod_name" : { 201 | "index" : "not_analyzed", 202 | "type" : "keyword" 203 | } 204 | } 205 | }, 206 | "log" : { 207 | "type" : "text" 208 | } 209 | } 210 | } 211 | } 212 | ``` 213 | 214 | **저장 데이터 예시** 215 | ```json 216 | { 217 | "_index":"logstash-2018.02.04", 218 | "_type":"fluent-logging", 219 | "_id":"AWFeY7RauuiH0H_zHFxS", 220 | "_version":1, 221 | "_score":1, 222 | "_source":{ 223 | "@timestamp":"2018-02-04T01:17:27.349Z", 224 | "log":"\u003cprobe\u003e WARN: 2018/02/04 01:17:27.349408 Cannot obtain local \ 225 | pods, reporting all (which may impact performance): Get http://localhost:10255/pods/: \ 226 | dial tcp 127.0.0.1:10255: getsockopt: connection refused\n", 227 | "stream":"stderr", 228 | "time":"2018-02-04T01:17:27.349642941Z", 229 | "kubernetes":{ 230 | "pod_name":"weave-scope-agent-56dfr", 231 | "namespace_name":"kube-system", 232 | "pod_id":"efe7252d-e565-11e7-b0d2-90e2bab4f938", 233 | "labels":{ 234 | "app":"weave-scope", 235 | "controller-revision-hash":"1130764677", 236 | "name":"weave-scope-agent", 237 | "pod-template-generation":"1", 238 | "weave-cloud-component":"scope", 239 | "weave-scope-component":"agent" 240 | }, 241 | "annotations":{ 242 | "kubernetes_io/created-by":"{\"kind\":\"SerializedReference\",\"apiVersion\":\ 243 | \"v1\",\"reference\":{\"kind\":\"DaemonSet\",\"namespace\":\"kube-system\",\"name\":\ 244 | \"weave-scope-agent\",\"uid\":\"efb7bba7-e565-11e7-b0d2-90e2bab4f938\",\"apiVersion\":\ 245 | \"extensions\",\"resourceVersion\":\"948\"}}\n" 246 | }, 247 | "host":"k2-node06", 248 | "container_name":"agent", 249 | "docker_id":"fe76859161a19a151e3dbec93db96231b9768452b818f3731f390a7985f4b003" 250 | } 251 | } 252 | } 253 | ``` 254 | 255 | ES의 다양한 기능을 사용하면 저장된 데이터에 대한 검색을 통해 원하는 로그를 찾아낼수 있고 필요한 통계의 추출도 가능합니다. ES는 인덱스, 타입, 필드 순의 자료구조를 갖고 있으며 필드에 구체적인 값을 저장합니다. 앞에 정의한 mapping(스키마)에서 각각 필드에 대한 속성을 정의하고 있으며 정의된 속성에 따라 가능한 검색기능이 제한됩니다. 256 | 257 | TACO Logging에서 저장하는 로그데이터에서 중요성을 갖는 필드들은 다음과 같습니다. 필드별 의미는 명칭에서 충분히 설명하고 있습니다. 해당필드를 사용하여 데이터를 검색하고 통계정보를 생성하면 수집된 로그에 대한 insight를 얻어낼 수 있습니다. 258 | * kubernetes.namespace_name 259 | * kubernetes.pod_name 260 | * kubernetes.pod_id 261 | * kubernetes.host 262 | * kubernetes.container_name 263 | * kubernetes.docker_id 264 | * kubernetes.label 265 | * app 266 | * application 267 | * component 268 | * release_group 269 | 270 | ### Fluent-logging chart 271 | 272 | TACO Logging을 구현하기위해 [fluent-logging chart](https://github.com/openstack/openstack-helm-infra/tree/master/fluent-logging)가 TACO팀 주도로 개발되었으며 앞의 Architecture 부분에서 언급한 것처럼 fluent, elasticsearch, kibana를 사용하도록 구현되었습니다. openstack-helm-infra에는 fluent-logging 외 ElasticSearch와 Kibana 차트도 제공되고 있으며 TACO 역시 해당 프로젝트에서 제공하는 챠트들을 사용하여 구축합니다. 273 | 274 | 사용자의 필요에 의해 기 구축된 ElasticSearch 사용하거나 다른 저장소의 사용 또한 가능합니다. 275 | 276 | ## Customization 277 | 278 | TACO Logging은 Kubernetes의 Helm 차트를 사용하여 배포합니다. Helm의 value-override 기능을 사용하면 구축시 필요한 다양한 요구사항을 변형할 수 있습니다. TACO Logging를 구성하는 ElasticSearch, Fluent-bit, Fluentd의 설정은 value-override 기능을 통해 재지정 가능합니다. 본 절에서는 몇가지 유용한 변경 예시를 살펴보고 간단한 설명을 통해 사용자가 필요한 요구조건을 반영하기위해 어떤 값을 변경시켜나갈 것인지에 대한 방법을 제시하고자 합니다. 279 | 280 | ### 간결한 구조 예시 (Fluent-bit/ElasticSearch) 281 | 282 | 현재 kubernetes에 대한 메타정보는 Fluent-bit의 plugin을 통해 입력되고 있습니다. 따라서 별다른 전/후처리가 필요하지 않다면 중간의 aggregation 단계를 생략하고 로그자체를 Fluent-bit -> ElasticSearch 로 전달하는 2단계 구성이 가능해 집니다. 이를 통해 만들어지는 EFK 구조를 도식화 하면 다음과 같습니다. 283 | 284 |  285 | 286 | fluent-logging의 value.yaml은 conf 필드에 개별 설정파일을 정의하고 있습니다. fluentbit의 설정은 conf.fluentbit 필드에서 정의하고 있으며 [Fluentbit 설정](https://fluentbit.io/documentation/0.12/configuration/file.html)을 참조하여 다음과 같이 변경하면 output을 ElasticSearch로 설정함으로써 위 구조를 적용시킬수 있습니다. (es_output) 287 | 288 | ```yaml 289 | conf: 290 | fluentbit: 291 | - service: 292 | header: service 293 | Flush: 1 294 | Daemon: Off 295 | Log_Level: info 296 | Parsers_File: parsers.conf 297 | - containers_tail: 298 | header: input 299 | Name: tail 300 | Tag: kube.* 301 | Path: /var/log/containers/*.log 302 | Parser: docker 303 | DB: /var/log/flb_kube.db 304 | Mem_Buf_Limit: 5MB 305 | - kube_filter: 306 | header: filter 307 | Name: kubernetes 308 | Match: kube.* 309 | Merge_JSON_Log: On 310 | - es_output: 311 | header: output 312 | Name: es 313 | Match: "*" 314 | Host: elasticsearch-logging 315 | Port: 80 316 | Logstash_Format: On 317 | HTTP_User: "admin" 318 | HTTP_Passwd: "changeme" 319 | ``` 320 | 321 | ### Federation을 위한 구축 예시 322 | 323 | Fluent-logging은 기본적으로 해당 클러스터에서 발생하는 로그에 대한 수용합니다. 따라서 모든 수집된 로그는 동일한 클러스터에서 발생된 것을 가정하고 있습니다. 경우에따라 다수의 클러스터에서 발생하는 로그를 하나의 TACO Logging에 수용하고 관리해야하는 경우 Federation 기능이 필요합니다. 이러한 구조는 다음과 같이 도식화 할수 있습니다. 324 | 325 |  326 | 327 | 다수의 클러스터에서 수집되는 로그들을 하나의 저장소에 보관하고 이를 구분하여 처리하기 위해서는 수집되는 클러스터의 명칭을 정의하는 것이 필요합니다. fluent-bit의 필터 중 [record_modifier](https://fluentbit.io/documentation/0.12/filter/record_modifier.html) 필터는 원하는 매타정보를 추가하는 기능을 제공하고 있으며 이를 활용하여 수집클러스터를 표기하도록 합니다. 328 | 329 | ```yaml 330 | - cluster_filter: 331 | header: filter 332 | Name: record_modifier 333 | Match: "*" 334 | record: cluster /* 클러스터 정보 ex> client */ 335 | ``` 336 | 337 | Federation을 위해 클러스터간 데이터 전달이 필요한데 이를위해 aggregator를 사용하면 다음과 같이 구성이 됩니다. 저장소가 위치한 클러스터(상단 그림의 Central LMA Cluster)의 aggregator의 노드포트를 설정합니다. (노드포트는 k8s에서 물리노드의 포트를 내부의 자원에서 사용할 수 있도록 하는 요소) 338 | 339 | ```yaml 340 | network: 341 | fluentd: 342 | node_port: 343 | enabled: true 344 | port: 32323 345 | ``` 346 | 347 | 로그를 수집하여 전달하고자하는 클러스터(상단 그림의 Cluster A/B)의 로그수집기는 앞에서 열려진 노드포트로 로그를 전달하도록 변경합니다. 348 | 349 | ```yaml 350 | - fluentd_output: 351 | header: output 352 | Name: forward 353 | Match: "*" 354 | Host: /* 서버 ex> 192.168.48.202*/ 355 | Port: /* 포트넘버 ex> 32323 */ 356 | ``` 357 | 358 | ## Conclusion 359 | 360 | 본 포스트에서는 TACO에서 제공하는 Logging mechanism과 주변 기술들에 대해 상세히 기술하였습니다. 또한 환경에 따른 변경 가능성을 몇가지 예시를 통해 제시하였습니다. TACO Logging은 kubernetes 클러스터 로깅 서비스로서 kubernetes에 올라가는 서비스라면 TACO외의 다른 서비스에서도 사용 가능합니다. 이후 개발방향은 Prometheus의 AlertManager 기능 연계를 통해 수집된 로그로부터 알람을 발생시키는 기능, 다양한 로그파일을 수집하는 기능 등이 추가될 예정입니다. 관심이 있는 분들은 [Openstack Review](https://review.openstack.org/#/q/project:openstack/openstack-helm-infra)나 [Virtualization Software Lab.의 github](https://github.com/sktelecom-oslab)를 통해 협업 가능합니다. 361 | 362 | [새로운 블로그]: https://openinfradev.github.io/ 363 | -------------------------------------------------------------------------------- /_posts/2018-04-13-Helm.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Helm : The Kubernetes Package Manager" 4 | date: 2018-04-13 11:00:00 +0900 5 | author: "김대성" 6 | --- 7 | 8 |by 김대성(daeseong.kim@sk.com)
9 | 10 | ## Update on 2019.07.30 [새로운 블로그]로 이전하였습니다 11 | 12 | ## Intro 13 | SK텔레콤의 클라우드 인프라 플랫폼 TACO는 지난 첫 포스트에서도 소개했지만 매우 다양한 오픈소스들로 이루어져 있습니다. 14 | 15 | 물론 그냥 가져다가 사용하는 것이 아니라 코드 기여 및 지속적인 미팅을 통해서 오픈소스 기술들을 내재화하고 있습니다. 16 | 17 | 이번 포스팅에서는 그 helm이라는 도구에 대해서 자세히 이야기해 보도록 하겠습니다. 18 | 19 | helm은 kubernetes cluster에 어플리케이션을 배포하는 도구입니다. 그리고 TACO는 Openstack을 kubernetes위에 container 형태로 배포하기 위해서 openstack-helm 프로젝트를 사용하고 있는데 이 프로젝트가 Openstack의 배포를 위해서 사용하는 도구가 바로 helm입니다. 20 | 21 | ## Helm 이란? 22 | helm은 deis라는 회사에서 시작한 Helm Classic 프로젝트와 Google에서 진행되던 GCS Deployment Manager 프로젝트가 합해진 프로젝트입니다. 23 | 24 | Helm Classic은 kubernetes에 어플리케이션을 올리고 관리하는 도구이고 GCS Deployment Manager는 kubernetes의 어머니격인 Google Cloud에 어플리케이션을 배포하고 관리하는 도구라서 서로의 목적이 같기 때문에 합해질 수 있었던 것 같습니다. 그렇게 deis와 google의 협업으로 진행되던 helm 프로젝트는 CNCF의 한 프로젝트로 완전히 오픈소스화가 되었습니다. 25 | 26 | helm은 chart라는 개념으로 어플리케이션을 정의하고 관리합니다. 그리고 이를 이용해서 어플리케이션을 kubernetes 위에 배포하고 이렇게 배포된 어플리케이션을 관리합니다. 27 | 28 | chart란 kubernetes에 올라갈 어플리케이션이 어떤 kubernetes 객체들로 구성되어 있는지, 어떤 설정값들을 사용하는지에 대한 정의가 담긴 정보의 집합이라 할 수 있습니다. 이번 포스팅에서는 helm 뿐만 아니라 chart의 구조에 대해서도 자세히 이야기해 볼 예정입니다. 29 | 30 | Project Links 31 | 32 | * Helm Code: