devops

쿠버네티스 컨테이너에서 정의되는 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..

Opstack Transaction L2의 트랜잭션은 L1인 이더리움에 먼저 기록되어야 한다. op-batcher가 L2 트랜잭션을 L1에 전송하지만, 모든 사용자는 batcher를 우회하기 위해 L1 트랜잭션을 전송할 수 도 있다. L2의 상태 업데이트를 위해 op-geth에서 트랜잭션이 실행된다. 그 후엔 op-proposer가 새 상태의 커밋을 L1에 전송한다. L2 Transaction Process 가장 먼저 user의 Tx는 L1의 batch inbox에 전송해야하는데, 여기서 트랜잭션들을 Batch로 압축하여 L1에 포스트하는 단계가 진행된다. op-batcher는 압축률을 최대화하기 위해서 시퀀서 배치를 채널로 나눈다. 채널이 채워지거나 시간이 초과되면 채널이 압축되고 저장된다. 1) L1..

Deposit을 L1의 거래 혹은 이벤트에 의해서 트리거되는 모든 L2거래를 의미한다고 한다. Deposit Flow 대부분의 Layer2는 Layer1의 네이티브 코인을 가스비로 사용하기 때문에 이 브릿지 과정인 Deposit과 Withdraw 프로세스를 아는 것은 아주 중요하다. (Deposit에는 ETH 혹은 토큰과 같은 자산이 포함되는 것이 보통이지만, 포함되지 않을 수 도 있다) Deposit, Withdraw 프로세스는 약간 Network stack이 작동하는 방식과 유사하다. 정보가 송신의 하위 계층에서 캡슐화되고 수신 측의 같은 하위 계층에서 수신하여 어플리케이션 계층으로 올라간다. L1 프로세스 1) L1의 컨트랙트 혹은 EOA(개인 계정)은 sendMessage 함수를 이용하여 L1Cr..

요즘 다양한 Layer2 SDK가 출시되고 있지만, Optimism가 가장 많이 사용되는 것같다. 코인베이스의 BASE부터 샘알트만의 Worldcoin, BNB의 L2인 opBNB까지.. 이미 Optimistic 롤업의 표준인 만큼 롤업에 관심있는 사람들이라면 Opstack의 아키텍처를 살펴보는 것은 중요하다. (Four Pillars 미디움 글을 참고했으며, 더 이해하기 쉽게 내용을 재구성했습니다. 틀린 부분이 있다면 지적해주시길 바랍니다.) Opstack Architecture Opstack 아키텍처는 위와 같이 4가지의 요소로 나뉜다. op-node, op-geth는 Layer2에서 노드의 역할을, op-batcher, op-proposer는 Layer1에 데이터를 전송하는 시퀀서 노드 역할을 수행..

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..

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 파일이 생성되어 있다. 이 테스트를 위해서는 ..

Helm 차트를 무작정 만드는 것은 쉬우나, 더 적은 코드로 효율적으로 짜는 것은 쉽지않다. 그러기 위해선 이미 잘 만들어진 Helm 차트를 한번 뜯어보고 어떤 흐름제어와 함수들이 사용되었는 지를 확인해보면 좋다고 생각한다. Prometheus는 웬만한 서비스들이 사용하는 모니터링 툴이자, 차트도 잘 짜여져있어 참고해보면 좋다. Prometheus Helm chart # Prometheus helm root path Chart.yaml Chart.lock README.md values.yaml templates - NOTES.txt - _helpers.tpl - alertmanager - node-exporter - server - pushgateway ... Chart dependency Helm 차트..

Istio? Istio는 오픈소스 서비스 메쉬로, 분리된 어플리케이션을 투명하게 계층화할 수 있다. 현재 쿠버네티스의 네트워크 구성에 가장 많이 사용되고 있는 오픈소스기도 하다. Istio는 쿠버네티스 네트워크의 복잡성을 줄이고, 분산 네트워크 환경에서 여러 어플리케이션들의 연결을 쉽게 설정할 수 있게 지원한다. Istio를 대표하는 3가지의 컨셉은 다음과 같다. Traffic management Sidecar 패턴(Pod 내에 Envoy proxy가 sidecar로 존재)을 이용하여 application 코드의 변경없이 작업자가 VirtualService, DestinationRule이라는 Custom Resource로 손쉽게 원하는 서비스로 트래픽 전송이 가능 k8s로 Canary 배포를 하기 위해선..

Provisioner 프로비저너는 카펜터를 시작할 때 기본적으로 사용되는 노드와 파드의 구성값, 제약 조건을 설정한다. pod의 리밋인 taint를 정의 node의 zone, instance type, computer architecture 정의 node expiration 정의 spec.requirements # Requirements that constrain the parameters of provisioned nodes. # These requirements are combined with pod.spec.affinity.nodeAffinity rules. # Operators { In, NotIn } are supported to enable including or excluding values..