TOUCHING ELEPHANT

이전에 작성했던 Tekton 글에 이어 마침 이번 주 CloudNeta 스터디 주제가 GitOps여서 Tekton, ArgoCD 를 결합한 CI/CD, GitOps 구현 예제를 작성해보려고 한다. 간단한 FastAPI 를 배포하는 예제이다. 구조 예제를 위한 평범한 GitOps 구조를 그려봤다. FastAPI app에 추가 변경사항을 반영해서 Repo를 업데이트하고나서 Tekton PipelineRun 으로 Trigger를 한다. 그러면 Tekton Pipeline에 정의된 순서대로 Task 3개가 동작을 시작한다. App repo를 clone 해와서 build 하고 DockerHub에 push한다. 이 과정에서 나온 image tag를 GitOps repo에 업데이트 한다. Slack으로 완료 메시지를..

PKOS2주차의 주제는 Networking 이다. 그 중에서도 Container networking 에 대해 정리해보려고 한다. Kubernetes networking의 고려사항 이 문서를 보면 어떤 고민들을 갖고 쿠버네티스의 네트워킹 모델이 등장했는지를 알 수 있다. https://kubernetes.io/ko/docs/concepts/cluster-administration/networking/ 💡 쿠버네티스는 애플리케이션 간에 머신을 공유하는 것이 핵심입니다. 일반적으로 머신을 공유하려면 두 애플리케이션이 동일한 포트를 사용하려고 시도하지 않도록 해야 합니다. 여러 개발자가 포트를 조정하는 것은 대규모로 수행하기가 매우 어렵고 사용자가 제어할 수 없는 클러스터 수준의 문제에 노출될 수 있습니다. ..

CloudNeta Kubernetes 스터디 시작 3월부터 가시다님의 CloudNeta Kubernetes 스터디에 합류했다. 이에 각 주차별 학습 내용을 정리해야 한다. 1주차의 내용은 KOPS를 사용한 K8S 환경 구축이다. KOPS란 무엇인가? Kubernetes KOPS는 Cloud 환경에서 Kubernetes 클러스터를 쉽게 배포, 관리 및 업그레이드할 수 있는 오픈소스 도구이다. KOPS는 클러스터를 생성, 업데이트 및 삭제하는 프로세스를 자동화한다. AWS, GCP 같은 CSP사의 환경에서 사용할 수 있다는데, Kops 깃허브에 가보면 DigitalOcean, Hetzner, OpenStack은 베타 지원, Azure는 알파 지원 중이라고 한다. KOPS는 클라우드에 Kubernetes 클러..

생산성 도구를 쓰기 시작한 건 회사를 처음 다니기 시작했을 무렵부터 였는데 벌써 몇 년이 지났다. 그 동안 더 좋은 도구와 방식을 찾아서 계속 헤매어 왔었는데, 사용해 본 도구들은 Evernote, Workflowy, Dynalist, Notion, Obsidian 이었다. 하지만 근 4년간은 Notion만을 사용했다. 그리고 매년 12월 말에 더 효율적으로 목표와 일정을 관리할 수 있도록 템플릿만을 바꿔왔을 뿐이다. 단지 Notion은 외부 저장소(AWS 인듯?)에 컨텐츠들이 저장되고 무조건 인터넷에 접속을 해야 사용할 수 있는 문제가 있다. 재작년인지 정확히 기억은 안나는데 미국 동부 AWS 데이터센터가 날아갔을 때 같이 접속이 안되는 문제가 있었다. 그래서 로컬에 글이 저장되고 ICloud를 통해 ..

TL; DR helm repo add deliveryhero https://charts.deliveryhero.io/ helm install deliveryhero/locust kubectl create configmap my-loadtest-locustfile --from-file path/to/your/main.py helm install locust deliveryhero/locust \ --set loadtest.name=my-loadtest \ --set loadtest.locust_locustfile_configmap=my-loadtest-locustfile 배경 Locust를 이용한 부하 테스트를 자주해야 하고 그 범위가 다양하다면 worker 수를 scalable 하게 다루고 싶어질 수 있..

CloudNet팀에서 진행하고 있던 Terraform study T101이 끝날 시간이 다가왔다. CloudNet팀의 스터디는 중간과 기말과제로 과제물을 만들어야 한다. 요즘 일이 많다보니 생각보다 시간이 부족해서.... 평범하게 현재 업무에 직접적으로 연관된, Terraform module을 이용해 여러 EKS 으로 쉽게 배포하는 내용을 최종과제로 작성하기로 했다. 사용하고 있는 Terraform의 기능들 Module 테라폼에서 모듈을 사용하면 기능 별로 테라폼 코드를 작성하고 이들을 재사용할 수 있다. 조금만 바꿔서 dev1, dev2, stage1, stage2 이런식으로 동일하게 여러 EKS를 배포할 수 있는 것이다. 이렇게 되면 동일한 코드를 여럿 작성할 필요가 없고 테라폼의 재사용성을 제대로 ..

멋진 CloudNeta 팀의 스터디에 이번에도 합류하게 되었다. 이번 주제는 Terraform 이다. 이번 스터디는 "테라폼 업앤러닝" 이라는 도서를 가지고 진행한다. Terraform 이라는건 IaC(Infra as Code)를 구현하는 도구이다. 왜 IaC인가? IaC, 그러니까 코드형 인프라는 왜 배우고 왜 써야 하는걸까? Infra As Code 라는 것인데, 선언적인 언어를 사용하여 인프라를 코드로 정의한다는 뜻이다. 그럼 운영환경을 완전하게 이식해서 코드로 관리할 수 있는걸까? 실수는 생기지 않을까? 이런 의문이 들법 하지만 일단 책에서 강조하는 IaC의 장점을 보면 아래와 같은 내용을 설명하고 있다. 자급식 배포 : 소수의 관리자가 점유하고 있는 인프라가 아니라 개발자가 필요할 때마다 배포를..

22.10.8 작성 TL; DR 그러니까 KServe라는 건 그냥 아주 쉽게 모델을 마운트해서 쓸 수 있게 다 코드를 준비해놓은 Tornado로 만든 웹서버인 것이다. 배경 KServe를 KFServing일 시절부터 테스트용으로 사용은 해왔지만 몇 개월 전부터 나름 production level로 사용을 하다보니, 한번 전체 구동 방식을 기록해두자 라는 생각이 들었다. 원래 KServe는 Kubeflow의 하부 프로젝트로 KFServing이라는 이름이었다. 그리고 0.7 버전부터 KServe라는 이름으로 변경되었고, KFServing에서의 migrating 을 지원한다. 현재 (22.10.8) 시점에서는 0.9버전이 release 되어 있으며, 점점 복잡해지는 Model Serving 들을 위한 기능이 ..

클라우드 네이티브 라는 말을 많이 듣기는 했지만 무슨 뜻인지 어렴풋이 짐작만 할 뿐이었는데, 이 책에서 그에 대해 설명을 한다. CNCF에서 내세운 정의를 언급하는데, "퍼블릭이나 프라이빗, 하이브리드, 멀티 클라우드와 같은 환경에서 실행할 수 있는 독립적인 비즈니스 기능 중심의 마이크로서비스들을 느슨하게 결합하여, 크기 조절이 가능하고 탄력적이며 관리와 관찰이 용이한 자동화된 소프트웨어 애플리케이션을 만드는 것" 이라고 설명한다. 와, 저러면 좋겠다 라는 생각이 드는 말이다. 저런게 클라우드 네이티브구나. 직무 특성상 자연스럽게 클라우드 환경에서 쿠버네티스를 다루게 되는 일이 많다. 컨테이너로 격리된 실험 환경, GPU 리소스의 자연스러운 분배, 각기 다른 다양한 모델의 서빙 테스트 들을 수행하기 위해..

지난 번에 이어 쿠버네티스 데이터베이스 오퍼레이터 스터디에서 진행한 학습의 실습한 내용을 기록한다. 이번 내용은 Strimzi Operator를 통해 Kafka를 쿠버네티스 상에 배포하고 테스트한 내용이다. Strimzi 설명 Stirimzi Operator의 기능 Strimzi는 쿠버네티스 환경에서 Kafka를 운영하기 위해서 만들어진 Operator이다. Operator로서 동작하기 때문에 Kafka의 많은 동작을 쿠버네티스에서 사용할 수 있도록 해준다. 간략하게 카프카 클러스터/구성요소 배포 및 관리, 카프카 접속 설정, 카프카 업그레이드, 브로커 brokers 관리, 토픽 topic 과 유저 user 생성 및 관리를 한다고 할 수 있다. 상세한 목록은 다음과 같다. Manages the Kafka..