목록DevOps (183)
devops
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/cX0SHl/btsHSYk0APF/YcFGswX5JNNPr8nx9KUInK/img.png)
service block은 port와 health check 등 job의 네트워크 서비스 디스커버리 및 헬스체크에 사용되는 것으로 provider의 기본 default값이 consul로 되어있다.그래서 nomad를 consul과 통합하여 사용하지 않는다면 아래와 같이 service의 provider에 nomad를 지정할 필요가 있다. service { name = "arbitrum-one" port = "http" tags = ["http"] provider = "nomad" check { type = "tcp" port = "http" interval = "10s" ..
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/GioHp/btsHRIjw8mw/EV8FDAXj4k8YNh4W3iOzj0/img.png)
Nomad는 내가 보기엔 아주 유용한 오케스트레이션 툴이지만, 국내에는 자료가 많이 없다. 직접 Nomad로 현재 운영 중인 베어메탈 서버에 Arbitrum full node를 배포해보는 테스트를 진행하려 한다. 그 과정에서 간단한 개념도 정리하려함.Nomad installwget -O- https://apt.releases.hashicorp.com/gpg | sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpgecho "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs..
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/JGYwq/btsHPn7GLob/s514EBuDISUr1wKvUE8w90/img.png)
하시코프의 Nomad는 Kubernetes에 비해서 간단하며, 다양한 워크로드를 지원, 지속가능한 배포와 확장성이라는 장점을 가진 오케스트레이션 툴이다.내가 현재 몸담고 있는 회사에선 여러 베어메탈 서버와 컨테이너들을 운영하고 있고 Disk 사이즈도 TB 단위로 사용하는 워크로드가 많다. 이런 조건에선 Kubernetes는 적합하지 않다. Kubernetes를 사용하면 자칫 노드당 하나의 컨테이너만 돌려야할 수 도 있고 바이너리로 실행되는 어플리케이션은 매니징하지도 못한다.오케스트레이션에 있어 가장 중요한 기능은 리소스를 효율적으로 관리하는 스케쥴링(Scheduling)이라 생각한다. Nomad의 스케쥴링은 어떤 방식으로 진행되고 어떤 요소들이 있는지 살펴보자.Nomad Scheduling Concept..
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/dPz6p5/btsDC62VGXu/PSHEAj3BZtk0vPiWbtT9L1/img.png)
Crossplane은 쿠버네티스 익스텐션 오픈소스다. K8S API를 통해서 쿠버네티스를 포함한 모든 리소스를 매니징할 수 있게 해준다. Cloud Native Compute Foundation(CNCF)의 프로젝트로, 현재 AWS, Azure와 같은 클라우드 리소스 매니징에 많이 사용된다. Crossplane? 쿠버네티스 클러스터로부터 외부, non-쿠버네티스 리소스와 연결하고 이 리소스를 활용하는데 사용됨 Kubernetes CRD로 만들어져 쿠버네티스 오브젝트의 external 리소스다. external resource의 state를 감시하고, state를 적용하는 쿠버네티스 컨트롤러 역할을 한다. Crossplane Components Crossplane의 강점은 Composition에 있다. 다..
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/Icbx6/btsCMzcSuk2/PUWfJZ8Y5JSxdJ46XlBFr1/img.png)
우리 팀에선 Loki-Prometheus-Grafana 스택으로 서비스 로그와 메트릭을 Grafana에 통합하여 모니터링하고 있다. 특히, Loki는 Container의 stdout, stderr 로그를 생성된 파드 기준으로 Promtail을 통해 수집하는데, debug 로그는 컨테이너 내부에서. log 파일 형태로 저장한다. 서비스 로그 레벨은 3으로 설정되어 있어, 문제가 생길 때마다 컨테이너에 있는 debug 파일을 확인하는게 아주 번거롭다. 그렇다고 로그레벨 수정을 위해 실행 중인 서비스를 재실행할 수 도 없었기에, retention을 최대한 줄이더라도 debug 로그를 수집할 필요가 있었다. 이 로그 파일을 로깅하기 위해서 고민했던 방식은 크게 3가지였다. hostpath로 노드에 컨테이너 로그..
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/DKLan/btsv7AX14Mn/WiziNCWuEk3bX8YLWkJ06K/img.png)
대부분 쿠버네티스 기반 모니터링에 특화된 Prometheus Operator를 활용하여 job을 추가한다. Prometheus Operator를 사용하면 일일이 kubectl patch를 통해 configmap에서 job을 추가하지 않고도 Service monitor 혹은 Pod monitor라는 CR로 쉽게 등록이 가능하다는 장점이 있다. 그러나 문제는 Service Monitor를 apply했는데도, Target에 등록조차 안되는 상황이 올때가 있다. kubectl get servicemonitor 를 확인하면 오브젝트가 정상적으로 apply된 상태임을 알 수 있다. 에러 메시지도 확인할 수 없는 상황. 사실 프로메테우스 오퍼레이터는 초기 배포 시 namespace와 label 키 값을 설렉터로 지정..
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/bLipIw/btsv7Ws3eCG/rcgcmkTd5figMkCok5OYgk/img.png)
Prometheus는 Memory와 CPU같은 하드웨어 리소스를 모니터링하는데 사용되므로 프로세스의 이벤트를 로깅하는데 한계가 있다. ELK 스택으로 개별 모니터링 파이프라인을 구축하기도 하지만, Grafana로 로깅에 최저화된 Loki를 사용하면 이미 Prometheus + Grafana로 메트릭을 수집하던 파이프라인에서 효율적인 로깅까지도 가능해진다. Loki Loki는 2018년 Grafana Lab에서 시작한 프로젝트로 수평 확장과 높은 가용성 그리고 멀티테넌시라는 특징을 가지고 있으며 낮은 비용에 운영이 간단하다. Store the logs in Loki Loki는 로그 텍스트를 인덱싱하지않고, 스트림으로 그룹화, 라벨링으로 인덱싱한다. 이를 통해서 비용 절감과 함께 로그 라인 쿼리를 짧은 시간..
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/bnYtKj/btsnTCOSpgx/LRuCjZhIkReSk3Ekc1mrck/img.png)
쿠버네티스 컨테이너에서 정의되는 Volume은 컨테이너의 데이터를 영구적으로 저장하거나 컨테이너 간 데이터를 공유하기 위해 사용된다. 각 볼륨은 여러 목적과 특성을 가지고 있어 상황에 맞게 사용된다. 복습 겸, 정리해보자. # Deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: productpage-v1 labels: app: productpage version: v1 spec: replicas: 1 selector: matchLabels: app: productpage version: v1 template: metadata: annotations: prometheus.io/scrape: "true" prometheus.io/port..
https://helm.sh/ko/docs/howto/charts_tips_and_tricks/ 차트 개발 팁과 비법 Covers some of the tips and tricks Helm chart developers have learned while building production-quality charts. helm.sh 위 helm 공식 문서에 차트 개발 팁과 비법이라는 내용이 있다. 이 내용과 더불어 몇 가지 추가적으로 정리해보자. 1. install과 upgrade 자동 실행 $ helm upgrade mychart . -n mychart-ns --create-namespace --install upgrade를 시도하는데, 기존 릴리즈가 없으면 install하는 명령어로 install과 u..
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/bfzjAU/btsmWk3j3kR/gLdKVFYFRIygKw8l40YeMK/img.png)
Prometheus 헬름 차트에 이어 이번에는 helm test 옵션이 있는 grafana 헬름 차트를 분석해보려고 한다. Grafana Helm chart # grafana helm repo Chart.yaml values.yaml README.md templates - NOTES.txt - _helpers.tpl - deployment.yaml - statefulset.yaml - clusterrole.yaml - tests (directory) Grafana의 template에는 tests라는 디렉토리가 있다. 이 tests는 마치 헬스체크처럼 kubernetes cluster에 grafana가 정 작동하는지를 헬스체를 한다. 아래와 같이 여러 yaml 파일이 생성되어 있다. 이 테스트를 위해서는 ..