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

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

EKS에는 기본적으로 Cluster Autoscaler가 있다. Karpenter가 나오기 전에 유일하게 노드를 확장해주는 방식으로, 여러 프로바이더를 지원한다.그러나 CA는 하나의 자원을 두 주체(ASG, EKS)가 각자의 방식으로 관리하기 때문에 관리 정보에 싱크가 맞지않아 여러 문제가 발생한다. 대표적으로 EKS에서 노드를 삭제해도 인스턴스(노드)가 삭제되지 않는 현상이 있다. 또한, CA의 노드 스케일인 옵션이 적고 느리다. CA의 문제점들 AWS Auto scaling에만 의존하여, 직접적인 노드 삭제와 생성이 안됨 EKS에서 노드 삭제해도 인스턴스가 삭제되지 않음 노드 축소 시, 특정 노드 축소가 어려움 Pulling 방식이기 때문에 API 제한이 걸릴 수 있음 스케일링 속도가 아주 느림 Ka..

우리 팀에서는 실제 여러 클라우드 환경에서 서비스를 운영, 테스트하고 있기 때문에 서비스 별로 각기 다른 config 파일을 관리해야 한다. 처음엔 환경마다 Parameter store를 이용해 파일과 key들을 관리했지만 환경에 접속해서 매번 수정하는 게 아주 번거로웠다. 특히나 github action에서 action을 위한 secret 환경변수도 레포마다 관리하는 것이 쉽지 않았다. 이렇게 흩어져있는 설정 파일 혹은 key값들을 중앙화시킬 필요가 있었고, 쿠버네티스를 사용하기 때문에 모든 환경에서 작동하는 컴포넌트의 배포 상태와 흐름을 파악할 수 있어야 했다. 이 요구사항들을 바탕으로 Vault, ECR, ArgoCD가 사용되는 Github action CICD 파이프라인을 구축하게 되었다. EKS..

Vault의 시크릿 엔진은 data를 암호화하고 저장하고 생성하는, 어떤 기능을 하는 유연한 특징을 가진 컴포넌트로 보면된다. 어떤 시크릿 엔진은 단순히 데이터 저장과 읽기만 제공하지만, 어떤 것은 서비스와 연결되어 동적인 Credential을 생성하기도 하고 인증 역할을 하기도 한다. 모든 시크릿 엔진은 볼트의 path를 통해서 활성화된다. 그래서 볼트에 요청이 올때 자동으로 해당 경로로 라우팅되어 처리된다. 시크릿 엔진은 개별 경로(path)와 속성이 정해져있기 때문에 사용하는 유저입장에서는 Virtual Filesystem이라고도 볼 수 있음 Lifecycle Enable : 시크릿 엔진의 경로와 함께 Enable된다. (몇몇 시크릿 엔진은 여러 경로로 Enable이 될 수 있음) 각 시크릿 엔진은..

ServiceAccount에 적용된 Role의 신뢰관계 설정 문제일 가능성이 크다. ServiceAccount가 AWS 리소스에 접근할 권한이 없기 때문. $ kubectl describe sa aws-load-balancer-controller -n kube-system 먼저 ALB Controller의 SA를 상세 정보를 확인하면, 위와 같이 Annotation에 선언된 Role을 확인할 수 있음. 위에선 AmazonEKSLoadBalancerControllerRole이 SA의 Role로 선언되어 있음. AmazonEKSLoadBalancerControllerRole을 확인해보면 아래와 같은 신뢰관계가 구성되어있다. { "Version": "2012-10-17", "Statement": [ { "Ef..