이스티오는 디버깅이 어려운 툴 중 하나라고 생각합니다. 그 이유는 간단하죠. 이스티오 자체가 어렵기 때문입니다. 서비스 메시 툴 답게 많은 네트워크 지식을 요구하기 때문에 디버깅이 어려울 수 밖에 없습니다. 네트워크 관련된 부분이 많기 때문에 어디서부터 디버깅을 해야 하는지 감도 사실 잘 안 옵니다. 이게 이스티오 문제인가? 클라우드 문제인가? 쿠버네티스 문제인가? 판단하기까지도 오래 걸리죠. 그러다 보니 애플리케이션을 배포하던 중 약간이라도 이스티오와 관련한 문제가 발생했다고 생각하는 경우 그냥 애플리케이션에서 이스티오를 빼버립니다. 정확히는 이스티오 사이드카(프록시)를 레이블을 통해 인젝션에서 제외시켜 버리는 것이죠.  이스티오 사이드카를 주입하지 않았기 때문에 대부분의 문제는 해결되지만, 이는 근본..

AWS 에서 GCP 로 넘어가면서 자연스레 AWS Secrets Manager 에서 GCP Secret Manager 로 넘어가게 되었습니다.서비스 이름이 AWS 에선 Secrets 복수를 사용하고, GCP 에선 Secret 단수를 사용하는데 글 후반부에서는 왜 이렇게 지었는지 대략적으로 알 수 있게 됩니다! Secret Manager 라는 서비스는 사실 특별한 기능은 없습니다. 그저 시크릿을 저장하는 저장소 역할을 하는데, 쿠버네티스 환경에서 External Secrets 나 Argo Vault Plugin 을 사용하면 원하는 시크릿을 쉽게 가져올 수 있다는 장점이 있습니다. AWS Secrets Manager 에 익숙한 상태였기 때문에 GCP 에서도 비슷하게 가져가면 될 것 같다라는 생각으로 마이그레..

해당 글은 이스티오 인 액션이라는 책의 일부 파트를 참고하였고, 책에서 다뤘던 방법보다 한 단계 더 나아가서 진행했던 내용을 바탕으로 작성하였습니다.이스티오 인 액션은 이스티오에 관한 책인데, 최근에 읽었던 중에 책 중에 가장 흥미롭게 읽은 책이였습니다.이스티오가 궁금하다면 많은 도움을 얻을 수 있는 책으로 적극 추천합니다! 다시 본론으로 돌아와서 ksniff 는 tcpdump 를 사용해 파드의 네트워크 트래픽을 포착하고 이를 와이어샤크로 리다이렉트하는 kubectl 플러그인입니다. ksniff 를 설치하기 위해선 우선 krew 를 먼저 설치해주어야 합니다. krew 문서로 가서 그대로 진행해줍니다. 저 같은 경우는 아래 쉘 스크립트를 실행시켰습니다.$ ( set -x; cd "$(mktemp -d)"..

해당 글은 AWS 범용 클라우드 아키텍처의 데이터 전송 비용 알아보기을 거의 다 참고했습니다! 클라우드 비용 절약은 IT 회사라면 늘 풀어야 할 숙제입니다. 어떻게 보면 풀 수 없는 숙제이기도 합니다. 그리고 AWS 클라우드와 EKS 를 운영하는 입장에서 비용은 적으면 적을수록 당연히 좋죠. 일부러 비용을 많이 나오게 하려는 엔지니어는 없을겁니다! 하지만... 결국 "누구에게나 그럴듯한 계획은 있다, 비용 청구서를 받기 전까지는" 같은 상황이 펼쳐집니다. 클라우드 비용 측면으로 봤을 때 크게 2가지로 나눌 수 있을 것 같습니다.데이터 전송량(Data Transfer)과 리소스 사용량(Resource Usage) 입니다. 이번 글에서는 AWS 에서 데이터 전송 비용을 아낄 수 있는 방법에 대해 설명하고자 ..

해당 글은 틀린 부분이 있을 수 있습니다. 마음껏 지적해주세요! 쿠버네티스 위에 있는 모든 파드와 노드는 ephermeral 하게 디자인 되었습니다. 그에 따라 파드와 노드는 언제 갑자기 급사? 할지 모릅니다. 하지만 급사 한다고 해서 서비스에 영향이 가선 안됩니다. 그렇기 때문에 쿠버네티스를 구성할 때 고가용성(HA) 은 반드시 동반되어야 합니다. 고가용성을 유지하지 위해서는 여러 절차가 동반되어야 하는데, 이번 글에서는 그 중 Stateful 한 서비스의 고가용성을 유지하는 방법 중 하나인 '리더 선출 메커니즘(Leader Election Mechanism)' 에 대해 알아보려고 합니다. 그 전에 Stateless 한 서비스의 고가용성부터 알아봅시다. Stateless 한 파드가 여러 개 있고, Se..

거의 두달이 넘도록 블로그 글을 작성하지 못했는데, 강의를 준비하느냐 그랬습니다!! 3개월 정도 준비를 했는데, 이제야 런칭을 하게되었습니다. 크지 않은 규모에서 쿠버네티스를 사용하면서 필요한 툴들이나 고가용성을 유지하기 위한 팁들을 다루는 강의입니다.쿠버네티스 기본 개념 강의는 아닙니다!   쿠버네티스 생태계는 CNCF 를 필두로 엄청나게 방대합니다. 그에 따라 어떤걸 사용할지도 쿠버네티스를 사용하면서 큰 고민거리입니다.또 IaC 를 이용해서 인프라를 코드로 관리하고 싶을텐데, 이러한 고민거리를 해결하는데 있어서 조금이라도 도움이 되었으면 하는 바람에 강의를 준비하게 되었습니다. 짧은 시간 내에 최대한 많은 걸 담아냈어야 했기 때문에 다소 부족한 부분이 있으나, "이런식으로 쿠버네티스가 돌아가는 구나"..

예전에 아래와 같은 글을 작성하였는데, 이후 크게 만지지 않아서 이번에 BIOS 모드 켜서 Proxmox 를 싹 밀어버렸고, 새롭게 다시 출발하자는 의미에서 Proxmox 재설치와 이번에는 Kubespray 를 이용해서 쿠버네티스를 설치했습니다. Proxmox 는 예전과 같은 방법과 똑같이 부품별로 구매해서 조립한 미니PC 에서 설치했습니다.저의 미니PC 가 궁금하다면 여기 클릭! 제 미니 PC 의 사양은 CPU 16, RAM 64GB, SSD 1TB 입니다. 그리고 총 4대의 Ubuntu Jammy 를 준비했고, 한대는 마스터로 나머지는 워커 노드로 사용했습니다.k8s-worker-03 도 4CPU 를 주고싶었지만.. 추후 다른곳에서 혹시 모를 CPU 를 사용할 수 있으니 2CPU 만 주었습니다.CPU..

틀린 부분이 있을 수 있습니다. 만약 있다면 지적해주세요 :)  쿠버네티스에서 ReplicaSet 을 통해 3개의 파드를 배포했다고 생각해봅시다. 이때 하나의 파드를 삭제하게 되면 곧 다시 파드가 생성됩니다. 즉, 파드가 최소 3개 이상이 실행되도록 ReplicaSet 를 배포했기 때문에 죽었던 파드를 새롭게 소생시킵니다. 이는 쿠버네티스의 특징 중 하나인 Self Healing 이기도 합니다.ReplicaSet, Deployment 등에서 명시하는 Replica 의 갯수는 고정/최대가 아닌 최소를 의미합니다.3개라고 가정했을 때, 롤링업데이트나 비자발적인 종료에 의해 3개 이상의 파드가 존재할 수 있기 때문이죠. 그럼 이걸 좀 더 전문적?으로 접근해봅시다. 우리가 원했던(Desired) ReplicaS..

이번 글의 주제인 "IRSA" 는 이해하기도 힘들었지만, 이걸 글로 작성하는 건 더 어려워서 많은 블로그 글들과 강의를 참고했습니다.틀린 부분이 있을 수 있으며, 아래에 명시한 참고 블로그들도 읽어주세요!  IRSA 는 IAM Roles for Service Account 의 약자로, Kubernetes 에서 AWS 리소스에 안전하게 접근할 수 있도록 하기 위한 메커니즘입니다. IRSA 를 사용하면 쿠버네티스 클러스터 내의 특정 Service Account 에 AWS IAM Role 을 매핑할 수 있습니다. 이를 통해 해당 Service Account 이 AWS 리소스에 접근할 수 있는 권한을 얻습니다.  IRSA 는 AWS 에서 제공하는 OIDC 와 IAM Role 을 사용하여 쿠버네티스 파드가 AWS..

드디어 kubestronaut 를 취득하였습니다!  계획대로 잘 풀려서 다행입니다. kubestronaut 은 CNCF 에서 임명하는 쿠버네티스 리더?로 CKA, CKAD, CKS, KCNA, KCSA 를 모두 취득하면 부여됩니다. CKA, CKAD, CKS, KCNA, KCSA 는 각 2년의 유효기간이 존재하지만 kubestronaut 은 유효기간이 없기 때문에 따놓으면 어찌됐든 좋다고 생각해서 CKS 가 만료되기 전에 빨리 따버렸습니다. kubestronaut 유효기간이 존재한다고 하네요 ㅜㅜ   심지어 kubestronaut 은 글 작성 기준으로 현재 저 포함 한국에 11명, 전 세계에 424명 밖에 되지 않습니다.  그리고 kubestronaut 되면 CNCF 홈페이지에 얼굴이 기재됩니다! (뿌듯..

CKAD 까지 취득하면서 kubestronaut 의 요구 조건을 충족시켰습니다! 일주일 내로 따로 메일을 준다고 하니 기다려야 하겠네요. 그럼 kubestronaut 후기는 다음 글에서 다루고, 이번 글에서 바로 CKAD 팁을 공유해보죠!  Tips 첫번째가장 먼저 역시 시험이 어떤 커리큘럼으로 진행되는지 확인해봐야겠죠? 뭐가 많긴 하지만, 어려운 파트는 없습니다. 쿠버네티스의 아주 기본적인 것들만 다루고 있습니다. 만약 실무에서 쿠버네티스를 써본 경험이 있다면, 무리없이 충분히 커버가 가능하다고 생각합니다. 두번째KCSA 와 KCNA 가 총 90분으로 진행되는 객관식 시험(Mutliple Exam) 이였다면, CKAD, CKA, CKS 는 총 2시간으로 진행되는 핸즈온 시험입니다. 따라서 상황이 주어진..

KCSA 시험은 꽤나 걱정스러웠는데 다행히 취득하면서 kubestronaut 까지 CKAD 만 남았습니다! 거의 다 왔습니다. 그럼 거두절미 하고 바로 팁으로 넘어가보죠!  Tips 첫번째 가장 먼저 역시 시험이 어떤 커리큘럼으로 진행되는지 확인해봐야겠죠? 아무래도 KCNA 와 달리 보안 관련한 항목들이 많습니다. KCNA 와 KCSA 는 CKA, CKS 보기 전 필기시험? 느낌인데, 저는 이미 CKS 를 취득했기 때문에 주제들이 엄청 이질적이진 않았습니다. 아! KCNA, KCSA 는 CKAD, CKA, CKS 와 달리 핸즈온 시험이 아닌 객관식(Multiple Choice Exam) 입니다! 그리고 60문제 총 90분으로 진행됩니다. 확실히 KCNA, CKA 얘네는 20분도 안걸렸는데, CKS 는 시..

CKA, CKS 까지만 취득하고, 쿠버네티스 자격증은 충분하다고 생각했는데 이번에 kubestronaut 라는 것을 접하게 되었습니다. kubeastronaut 는 5개의 쿠버네티스 자격증 CKAD, CKA, CKS, KCNA, KCSA 를 모두 취득하면, 리눅스 파운데이션에서 주어지는 칭호?입니다. 그래서 어차피 CKS 도 취득했겠다, 나머지도 취득해야겠다고 마음 먹었습니다.  그렇게 마음 먹고 그 마음 먹은 주에 바로 KCNA 를 취득하였습니다. 그럼 바로 팁을 공유해보죠! Tips 첫번째 가장 먼저 역시 시험이 어떤 커리큘럼으로 진행되는지 확인해봐야겠죠? 뭔가 엄청 많은거 같은데, CNCF 프로젝트와 쿠버네티스를 조금이라도 다뤄보셨다면 사실 공부하지 않아도 어렵지 않게 취득할 수 있을거라 생각합니다..

비록 크지 않은 규모의 쿠버네티스지만 2년 동안 운영하면서 많은 것들을 경험할 수 있었습니다. 경험속에서 배울 수 있었던 작은 팁들을 공유하고자 합니다. 제가 공유하고픈 팁들은노드 및 파드 스케줄링HA 유지쿠버네티스 매니페스트 관리IaC입니다. 그럼 바로 본론으로 가보죠. 렛츠두더코드~   노드 및 파드 스케줄링 쿠버네티스를 처음 공부했을 때, 노드 및 파드 스케줄링 파트는 그렇게 유심히 보지 않았습니다. 그렇게 어려워 보이지 않았거든요. 그냥 Resource Request/Limit, NodeAffinity/PodAffinity/AntiAffinity 등 yaml 에 작성하면 파드는 그에 맞게 알아서 배포가 되니깐요. 당연한 것이 공부할땐 기껏해야 3개 정도의 파드로 진행하는데, 현실에선 최소 몇 백개..

현재 글은 상편에서 이어집니다.들어가기 앞서 해당 글에서는 C Compiler 에 대한 지식을 필요로 합니다. 하지만 전 C Compiler 에 대해 자세히 알지 못하기 때문에 틀린 부분이 있을 수 있으며, 언제든지 지적바랍니다. 그리고 Github Action 과 관련된 개념 부분은 따로 설명하지 않습니다.  시나리오는 크게 Local 영역과 Remote(Git Runner) 영역으로 나눌 수 있습니다.  Local Local 영역부터 시작해보죠. Local 영역에선 미리 Python 을 빌드 한 후에 Artifacts Repository 에 업로드 합니다.Official Setup Python 액션을 보면 versions-manifest.json 에 Python 을 다운받을 수 있는 URL 이 명시되..

들어가기 앞서 해당 글에서는 C Compiler 에 대한 지식을 필요로 합니다. 하지만 전 C Compiler 에 대해 자세하게 알지 못하기 때문에 틀린 부분이 있을 수 있습니다. 지적은 언제든지 환영합니다 :) Github Action Marketplace 에는 다양한 액션들이 존재합니다. 그 중 Setup Node, Setup Go, Setup Python 액션 등을 통해서 필요한 언어나 툴을 러너에 설치하게 됩니다. 만약 러너에서 파이썬이 필요하다면,  Setup Python 액션을 실행해서 파이썬을 사용할 수 있는 환경을 구성할 수 있습니다.  그런데,  아쉽게도 Setup Python 액션은 Linux x64, Windows x64, MacOS Apple Silicon(Intel 포함) 은 지원..

k6 는 Grafana 사에서 제공되는 퍼포먼스 테스트 툴입니다. k6 를 이용하면 마치 여러 명의 유저가 있는 것처럼 애플리케이션 퍼포먼스 테스트를 진행할 수 있습니다. Smoke Test, Load Test, Stress Test 등 다양한 테스트를 쉽게 진행할 수 있도록 도와줍니다. 그리고 자바스크립트로 제공되기 때문에 어렵지 않게 테스트 시나리오를 작성할 수도 있죠. 아래는 아주 간단한 k6 스크립트입니다.import http from 'k6/http';import { sleep } from 'k6';export const options = { vus: 10, duration: "10s",}export default function() { http.get('http://test.k..

테라폼은 대표적인 IaC 도구로 AWS 와 같은 클라우드 환경을 코드로 구성할 수 있다는 장점이 있습니다. 그리고 보통 클라우드 환경은 Dev 과 Prod 으로 나뉘게 됩니다.  한편, 테라폼을 이용해서 리소스를 생성하게 되면 backend 라는 곳에 tfstate 를 저장하게 됩니다.tfstate 는 리소스의 구성 정보를 가지고 있는 파일이고, backend 는 이러한 tfstate 를 저장하는 보관소 입니다. backend 는 로컬이 될 수도 있고, AWS S3 와 같은 오브젝트 스토리지도 될 수 있습니다. 한번, AWS S3 에 Demo 버킷을 Dev 환경과 Prod 환경에 같은 코드를 가지고 동일하게 생성한다고 가정해보겠습니다. 예제 코드는 여기서 가져왔습니다! 사용..

이전 글인 [트러블 빵야] 6개월 동안 즐거웠다.. 잘가고 다신 보지 말자! - 504 Gateway Timeout (이슈 편) 에서 이어집니다! 곰곰이 생각해봤습니다. 504 Gateway Timeout ... 결국 어디선가 Response 를 받아야 하는데 받지 못해서 생기는 이슈 입니다. 어디서 Response 을 받지 못했을까요? 위 아키텍처만 봤을땐, 더 이상 도저히 모르겠습니다.  그래서 위 이미지보다 조금 더 아키텍처를 구체화시켜봤습니다. AWS ALB 는 Target Group 에 등록된 노드에게 트래픽을 라우팅 해주는데, Karpenter 로 생성되는 노드들은 모두 동일한 Target Group 에 등록됩니다. (대수롭지 않게 동일한 Target Group 에 등록되게끔 구성했죠) 여기서..

개발을 하는데 있어 컨테이너는 더 이상 빠질 수 없을 만큼 중요한 개념이 되었습니다. 그리고 Docker 는 컨테이너 매니지 툴 중 가장 대표적이라고 볼 수 있죠. 컨테이너를 실행하기 위해선 이미지가 필요하고 보편적으로 Docker 를 통해 이미지를 만들게 됩니다. Dockerfile 에 작성 한 후 Docker 커맨드를 이용하면 이미지가 만들어지고 아주 쉽게 컨테이너를 실행할 수 있습니다. 이미지를 빌드 하는 데 있어서 물론 경량화도 중요하지만, 그 못지 않게 이미지 보안도 중요합니다. --previliged 권한을 부여하는 걸 지양하고, Dockerfile 에 직접적으로 crendentials 관련한 정보를 추가(COPY) 하는 걸 주의해야 합니다. trivy 를 이용하면 손쉽게 이미지의 취약점 검사..

쿠버네티스 클러스터에는 3가지의 AutoScaler 가 있습니다. HPA, VPA, CA 죠. 간단히 설명해보자면, HPA : Horizontal Pod Autoscaler 의 줄임말로, 파드의 갯수를 확장/축소 해줌 VPA : Vertical Pod Autoscaler 의 줄임말로, 파드의 갯수가 아닌 지정된 리소스를 확장/축소 해줌 CA : Cluster Autoscaler 의 줄임말로, 노드의 갯수를 확장/축소 해줌 HPA, VPA 는 Metrics Server 가 설치되어 있어야 하며, 또 VPC 같은 경우는 따로 설치해주어야 합니다. 그리고 CA 는 보통 Karpenter 를 사용합니다. 이번 글에서는 HPA 에 대해 다뤄보고자 하는데, 사실 HPA 는 어려운 개념이 크게 없다고 생각합니다. 따..

테라폼을 처음 시작하면 헷갈리는 명령어 옵션이 있습니다. 바로 terraform init 명령어의 -migrate-state 와 -reconfigure 죠. 보통 backend 구성을 변경하면 해당 옵션을 사용하라는 명령어를 볼 수 있습니다. 로그에서 -migrate-state 와 -reconfigure 에 대한 설명이 나와있지만 딱히 와닿지는 않습니다. tfstate 의 방향성을 좌지우지 하는 옵션이기 때문에 잘못 썼다간 인프라가 꼬일 수도 있습니다. 예를 들어, 분명 변경(0 to change)하는 건데 새롭게(1 to add) 생성한다는 문구를 볼 수 있죠. 이런 경우는 보통 backend 구성을 변경하고, -reconfigure 를 사용했을 때 발생합니다. 예제여서 딱 하나의 state 만 존재하..

쿠버네티스 내부끼리 통신을 할 때 보통 서비스의 도메인 svc.cluster.local 을 이용하여 통신하게 됩니다. 외부에서 내부로 들어오는 통신에 대해서는 Ingress 를 이용해 https 통신을 하게되죠. 하지만 Ingress 는 내부 통신에 대해서는 https 통신을 보장해주진 않죠. 이 부분에 대해서는 Istio 의 mTLS 를 이용해서 파드와의 통신은 모두 https 통신을 하게 할 수 있습니다. Istio 의 mTLS 가 궁금하다면? [Istio] 쉿! 우리만의 비밀이야 - mTLS (확인편) [Istio] 쉿! 우리만의 비밀이야 - mTLS (검증편) 그렇다면 mTLS 를 이용하지 않고 내부 통신은 어떻게 https 통신을 할 수 있을까요? 정답은 간단합니다. 파드 마다 certifica..

EKS 와 같은 클라우드가 제공해주는 쿠버네티스가 아닌, 온프레미스 환경에서 쿠버네티스를 설치한다고 하면 보통 kubeadm 이라는 툴을 이용해서 구성하게 됩니다. Control Plane 은 kubeadm init 를 통해 구성되고, Data Plane 은 kubeadm join 을 통해 쿠버네티스에 조인하게 됩니다. kubeadm 툴 하나면 API Server, Scheduler, Control Manager, ETCD 등 Control Plane 에 필요한 모든 것들이 마법처럼 자동으로 구성되죠. 물론 kubelet 그리고 containerd 와 같은 cri-구현체는 이미 실행되고 있어야 합니다! 자동이란 것이 확실히 편의성을 제공해주긴 하지만, 자동으로 구성되기 때문에 그 안에서 무슨 일이 일어..

예전부터 쿠버네티스를 관리하는 데 있어서 궁금한 점이 있었습니다. "엄청 나게 많은 로그를 생성하는 애플리케이션들로 인해 노드의 디스크가 부족해지면 어떡하지?" "계속 새로운 컨테이너 이미지를 다운 받아서 그로 인해 노드의 디스크가 부족해지면 어떡하지?" 노드의 디스크가 부족하게 되면 노드에서 DiskPressure 라는 메시지를 뱉게 될 것입니다. 그런데 궁금한 요점은 디스크가 부족할 때 "어떻게 해결하냐" 가 아니고 "어떻게 예방하냐" 입니다. 그래서 이번 글에서는 예방하는 방법에 대해 알아보고자 합니다. 렛츠두더코드~ 저는 개인적으로 쿠버네티스를 관리하면서 가장 중요시하게 생각하는 키워드가 있습니다. 바로 일시적(empheral) 과 동적(Dynamic) 입니다. 예를 들어, 쿠버네티스의 가장 기본..

앞서 작성했던 트러블 슈팅 관련 글 중에 한 글은 제목이 "타노스는 이런 느낌일까?" 라고 지었을 만큼 꽤나 힘들었던 에러였죠. 근데 이번에 겪은 이슈는 앞선 글 제목에 타노스 라고 붙이기 민망할 정도로 원인을 찾기가 힘들었고, 또한 이슈가 6개월이나 지속될 정도로 마음 아팠던 트러블 슈팅이였습니다.  들어가기 앞서 간략하게 환경은 다음과 같아요. 쿠버네티스는 AWS EKS(v1.28) 를 이용하고 있으며, 서비스메시 서비스인 이스티오(v1.18)의 인그레스 게이트웨이와 AWS ALB 를 맵핑하여 클러스터 외부에서 클러스터 내부 서비스에 접근이 가능합니다. 그리고 여기서 사용할 내부 서비스는 ArgoCD(v2.5) 입니다. 이슈는 ME! 가 ArgoCD 에 접근을 했을때 불특정하게 504 Gateway ..

쿠버네티스 환경에선 ARC 를 이용하면 어렵지 않게 다양한 OS 위에 오토스케일링에 기반한 Runner 구현이 가능합니다. Karpenter 와 함께라면 더 효율적이죠. (Karpenter 과 궁금하다면 여기 참고, ARC 가 궁금하다면 여기 참고) 또한 EKS 에서 Linux 와 Windows 기반의 노드를 지원해주기 때문에 띄우기만 한다면 파드 단위로 Runner 를 배포할 수 있습니다. (EKS 에서 Windows 를 활성화 하는 방법이 궁금하다면 여기 참고) 하지만 MacOS 는 얘기가 달라요.. EKS 에서 지원을 안해줍니다.. 그래서 만약 MacOS 기반의 워커 노드를 프로비저닝 하려고 한다면, 아마 MacOS 기반의 인스턴스를 띄운 후 거기서 수동으로 EKS 클러스터에 조인해야 할 것입니다...

들어가기 앞서 저는 Windows 를 많이 다뤄보지 않았기 때문에 부족하거나 틀린 부분이 있을 수 있습니다! 쿠버네티스는 v1.23 버전, Karpenter 는 v0.31 버전입니다. 쿠버네티스(EKS) 환경에 윈도우와 Karpenter 를 활성화 하는 방법에 대해선 여기를 참고하세요. Karpenter 에 대해 궁금하다면 여기를 참고하세요. 그럼 렛츠두더코드~ 우리가 쿠버네티스를 사용하는 방법은 바로 오케스트레이션을 위함이죠. 하나의 마스터 플레인으로 여러 노드의 여러 파드를 좀 더 쉽게 관리하기 위해서입니다. Action Runner 역시 예외는 아니죠. Action Runner Controller 를 이용하면 쉽게 쿠버네티스 환경에서 파드 단위의 Runner 배포가 가능합니다. 맨 처음 Action..

우리는 보통 EKS 의 워커 노드로 x86 이든, arm64 이든 리눅스를 사용합니다. 특히 EKS 환경이라면 아마존 리눅스2를 사용하겠지요. 근데 간혹 워커 노드로 윈도우를 필요로 하는 경우가 있습니다. 예를 들어 라이브러리를 만들었는데, 리눅스 뿐만 아니라 윈도우 환경에서도 이 라이브러리를 필요로 합니다. 그렇다면 이 라이브러리를 이미지로 빌드하려면 리눅스가 아닌 윈도우 환경에서 만들어야 하죠. 다행히 EKS 는 윈도우를 지원해줍니다. 또한 Karpenter 에서도 윈도우를 지원해주죠. 그럼 어떻게 EKS 환경에서 윈도우를 활성화 하는지, 이후 Karpenter 에서 윈도우를 어떻게 프로비저닝 하는지 한번 알아보도록 하죠. 참고로 진행한 쿠버네티스 버전은 1.23 이고, Karpenter 는 0.31..

개발을 하다보면 한가지 버전뿐만 아니라 다양한 버전을 지원해줘야 합니다. 예를 들어 파이썬을 사용한다면 3.8, 3.9, 3.10 버전 모두 지원해주어야 하죠. 버전뿐만 OS 도 Linux x86, arm, Window, MacOS 등 다양하게 지원해주어야 합니다. C/C++ 로 만들어진 프로젝트를 swig 를 통해 파이썬, 자바, Go 등 다양한 언어과 다양한 버전에서 사용할 수 있는 패키지를 만들어야 했던 적이 있습니다. C/C++ 프로젝트에 사용되는 CMakeLists.txt(cmake) 와 Github Action 의 matrix 를 이용하면 어렵지 않게 다양한 버전의 패키지를 만들 수 있을 거 같습니다. 이번 글에서는 파이썬과 Linux x86 만 다루며, 3.8, 3.9, 3.10 버전의 파이..