C/C++ 기반의 프로젝트를 빌드하는데 있어 보통 cmake 와 make 를 이용해서 빌드를 하게 됩니다. 간략하게 cmake 는 CMakeList.txt 를 기반으로 Makefile 를 만들어주고, make 는 Makefile 를 통해 프로젝트를 빌드합니다. cmake 는 빌드를 위한 프로세스이고, make 는 실제로 빌드를 해주는 프로세스인 셈이죠. 그런데 C/C++ 프로젝트를 빌드하는데, 빌드 시간이 대략 1시간 정도 소모됩니다. 너무 오래걸려요.. 진행한 runner 는 2GB Memory 의 인스턴스입니다. 빌드 시간을 단축시키고 싶습니다. 빌드 시간을 단축시키기 위한 방법으로 가장 먼저 떠오르는 것은 바로 캐싱 입니다. 매번 같이 파일을 빌드하지 말고, 반복되는 빌드 파일을 캐싱해놓으면 시간이..

지난 글에서 Cloudflare 에서 생성한 도메인과 Let's Encrypt 를 이용해서 TLS 를 httpbin 에 적용했었습니다. 이번에는 Cloudflare 보다 더 대중적인 Route53 에서 생성한 도메인에도 TLS 를 적용해보고자 합니다. Route53 에서 구매한 도메인에 대해서는 AWS ACM 을 이용해서 무료로 TLS 를 발급받을 수 있습니다. 그리고 발급받은 TLS 를 AWS ALB 에 바로 적용하게 되면 아주 쉽게 TLS 통신이 가능합니다. 그래서 ALB 와 Istio 를 이용하게 되면 대략 아래 그림과 같죠. 하지만 외부만 TLS 를 통신이 가능하므로 내부에선 TLS 통신이 불가능합니다. ACM 을 통해 도메인에 대한 Cert 를 발급받을 수 있는데, 이 값은 다운받아서 사용불가능..

이 글은 TLS 에 대한 기초적인 개념이 필요합니다. 최소한 HTTPS 가 어떻게 동작하며, CA, CSR, tls.cert 등과 같은 것이 무엇인지 알아야 합니다. 미니 PC 에서 쿠버네티스 클러스터를 구성하여 이것저것 해보고 있는데, 늘 하나 마음에 걸리는 것이 있었습니다. 바로 도메인과 TLS 입니다! 도메인 같은 경우 맥 /etc/host 에 추가해서 사용하고 있었고, TLS 가 적용되지 않다보니 늘 주의 요함을 달고 있었죠. AWS ALB 를 사용하면 Route53 과 ACM 을 통해서 TLS 적용하기 쉽지만, AWS 없이 TLS 를 적용하려면 결국 TLS 를 구매해야 합니다. TLS 는 보통 유료인데, Let's Ecrypt 는 무료로 TLS 을 제공해주기 때문에 이번 글에서는 로컬 환경에서 ..

지난 글에서 Istio mTLS 에 대해 알아보았고, 적용도 해봤습니다. 또 Kiali 를 통해서 실제 mTLS 가 적용 되었는 지도 알아봤죠. Kiali 에서 mTLS 가 적용됐다고 아이콘으로 표시를 해주긴 하는데 제 눈으로 직접 암호화가 되는지 확인하고 싶습니다. 그래서 이번 글에서는 Istio 공식 문서에서 제공해주는 예제와 tcpdump 를 이용해서 한번 확인해보죠! 렛츠두더코드~ 들어가기 앞서 주의할 점이 있습니다! istio-proxy container 에서 tcpdump 를 사용하려면 sudo 를 권한을 가질 수 있도록 privilege 를 true 로 주어야 합니다. 따라서 아래 명령어를 통해 istio 를 설치합니다. $ istioctl install --set values.global...

EKS 에 배포된 파드들은 AWS 에 접근하기 위한 방법으로는 크게 2가지가 있습니다. EC2 Instance Profile IAM Role for Service Account EC2 Instance Profile 은 워커 노드에게 AWS 에 접근할 수 있는 자격 증명을 해주죠. 정해진 EC2 인스턴스에 정해진 애플리케이션을 배포한다면 위 방법은 아주 좋은 방법이에요. 하지만, 쿠버네티스 환경에 배포되는 파드들은 하나의 특정한 노드에 배포되지 않아요. NodeAffinity 와 Label 을 통해서 노드를 제한하긴 하지만 느슨하게 그룹핑을 하죠. 만약 쿠버네티스 환경에서 App 이 Replica 3 개로 배포되고, Hard PodAffinity 를 주어 파드를 전부 다른 노드에 배포되게끔 한다면, 또 다..

쿠버네티스에선 컨피그맵과 시크릿을 통해 환경변수나 파일을 전달해줄 수 있습니다. 특히 민감한 정보인 경우 시크릿을 통해 배포하게 됩니다. 하지만 시크릿은 문제가 하나 있습니다. 이름은 시크릿인데.. 인코딩만 해줄뿐 전혀 시크릿스럽지 못합니다. 따라서 시크릿을 사용하는 Helm Chart 을 생성한 후, 깃허브에 올리게 된다면 결국 그 시크릿 값은 그대로 노출됩니다. 프라이빗 레포지토리라 해도, 민감한 정보는 깃 허브에 올리면 안된다고, 깃헙 자체에서도 가이드합니다 그럼 이런 시크릿을 어떻게 시크릿스럽게 사용할 수 있을까요? 다행히 이미 좋은 솔루션이 존재합니다. 바로 HashiCorp 의 Vault 입니다. Vault 는 Secret Manager 시스템으로 이름 그대로 시크릿을 관리해주는 시스템입니다...

스토리지와 관련된 쿠버네티스 리소스에는 StorageClass, PersistentVolume 이 있습니다. 보통 동적인 스토리지는 원한다면 StorageClass (이하 SC) 를, 정적인 스토리지를 원한다면 PersistentVolume (이하 PV) 을 사용합니다. 한편, 파드에서 스토리지 연결을 하려면 PersistentVolumeClaim (이하 PVC) 을 이용해서 SC 나 PV 를 Bound 해주어야 합니다. AWS EBS 를 사용하게 될 텐데, EBS 만으로는 한계가 있습니다. 바로 하나의 EBS 는 다중 인스턴스 연결이 되지 않는다는 점이죠. 예를 들어 EBS 에 데이터를 저장하는 애플리케이션을 Deployment Replica 2 로 배포한다고 가정해보죠. 그리고 파드들은 서로 다른 워..

2023년 07월 17일 기준으로 작성되었으며, 시험 버전은 SAA-C03 입니다. 버전 업이 되면 달라질 수 있으니 읽기 전 꼭 버전 확인 부탁드립니다. 첫 AWS 자격증을 획득했습니다. 역시 출발은 SAA 로 하는 것이 국룰이죠! 아래는 AWS 자격 종류입니다! 난이도는 기초 > ASSOCIATE > PROFESSIONAL > 전문 분야 순입니다. SAA 는 ASSOCIATE 레벨의 Solutions Architect 입니다. 그럼 바로 팁을 공유하겠습니다! Tips 첫번째 다른 자격증과 마찬가지로 비용이 꽤 비쌉니다. 레벨마다 비용은 상이하지만 ASSOCIATE 는 150$ 입니다. 원화로 치면 대략 20만원입니다. 쿠버네티스에 비하면 싸긴 하지만.. 여전히 부담스러운 가격입니다..!! (쿠버네티스..

쿠버네티스 위에는 다양한 서비스들이 존재합니다. 이 서비스들이 하나하나 생겨나다 보면 어느 새 몇 백개, 몇 천개의 서비스들이 존재하게 됩니다. 이런 서비스들을 쉽게 관리하기 위해서 이스티오를 사용합니다. 이스티오는 서비스 메쉬 서비스 라는 타이틀에 걸맞게 다양한 기능들을 제공해주는데 이번 글에서는 그 중 핵심 기능 중 하나인 mTLS (Mutual TLS) 에 대해 알아보고자 합니다. 먼저 mTLS 가 무엇인지 알아보기 전에 왜 필요하진 부터 알아보죠. 이스티오 인그레스 게이트웨이를 통해 우리는 쿠버네티스 내부에 접근이 가능합니다. 클라이언트가 데이터를 전송할 때 암호화를 한 후 전송하게 되는데 (HTTPS), 문제는 인그레스 게이트웨이 까지만 데이터가 암호화가 되고 쿠버네티스 내부에서는 HTTPS 가..

Karpenter 는 AWS 에서 진행 중인 오픈 소스 프로젝트로 쿠버네티스에서 AWS ASG 보다 한 차원 높은 수준의 스케일링을 제공해줍니다. Karpenter 가 무엇인지 모르겠다면 여기를 참고! Karpenter 를 이용하면 CPU 인스턴스 뿐만 아니라 GPU 인스턴스 또한 정말정말 유동적으로 프로비저닝 할 수 있습니다. Karpenter 를 쓰면 쓸 수록 "와 이거 진짜 짱인데?" 라는 생각이 많이 듭니다. 아주 유용한 프로젝트인거 같아요. CPU 인스턴스 같은 경우에는 Karpenter 만 설치하면 프로비저닝, 디프로비저닝 모두 잘 동작합니다. 하지만 GPU 인스턴스 경우 프로비저닝은 잘되지만, 디프로비저닝은 동작하지 않아요. 처음에는 아직 메이저 버전이라서 GPU 관련한 기능이 개발이 안된 ..

지난 글에서는 Action Controller Runner (이하 ARC) 를 사용할 때 AWS EFS 를 마운트해서 특정 경로에 build 에 필요한 데이터를 캐싱했습니다. 근데 만약 AWS EFS 와 같은 데이터를 저장할 수 있는 스토리지가 없다면 어떨까요? 다행히 충분히 좋은 대책안이 있습니다. 바로 Github Action 에서 제공해주는 Action Cache 이라는 녀석입니다. Github Action 을 사용한다면 아마 이미 다들 잘 아실 수도 있겠군요. Action Cache 는 좋아요 3.7k 를 받을 만큼 많은 사랑?을 받고 있는 액션 중의 하나입니다. 도큐먼트를 보면 꽤 자세하게 설명이 되어있습니다. 예제 코드도 존재하며, 각 필요한 with 에 대해서도 친절하게 설명해주고 있습니다...

Istio (이하 이스티오) 는 쿠버네티스의 대표적인 서비스 메쉬 소스입니다. 뿐만 아니라 이스티오는 인그레스 컨트롤러도 제공해주기 때문에 Nginx 와 같은 별도의 인그레스 컨트롤러가 필요 없어요. 이번 글에서 Istio 의 핵심 자원인 IngressGateway 에 TLS 를 적용시켜 보고자 합니다! Istio 를 설명하는 글이 아니기 때문에 Gateway, VirtualService 와 같은 리소스에 대한 설명은 하지 않겠습니다. 그럼 렛츠두더코드~ 실습 환경은 아래와 같아요. 쿠버네티스 v1.26.2 이스티오 v1.17.2 공식 문서에 나와있는 예제는 불필요한 내용이 많아서 딱 필요한 부분만 실습하려고 합니다. 만약 더 자세한 정보가 궁금하다면 여기를 참고해주세요. TLS 를 적용 할 것이기 때문..

매우매우매우 중요! Karpenter v0.32 버전부터 리소스 이름들이 변경되어 참고 바랍니다. 개념은 똑같습니다. (ex. Provisioners -> NodePools) Karpenter 의 개념을 알고 싶다면 여기 참고! Karpenter 를 파면 팔수록 정말 유용한 오픈소스인거 같아요. ASG 를 넘어서 훨씬 효율적이고 유동적으로 노드와 파드를 관리할 수 있게 해주거든요. 스케줄링 시스템을 개발하고 있는데, Karpenter 가 없었다면 많이 힘들었을 겁니다... 이번 글에서는 Karpenter 의 Deprovisioning 에 대해 알아보려고 합니다. 가장 핵심이라고 볼 수 있죠. Deprovisioning 관련 옵션은 크게 2가지로 나눌 수 있어요. - ttlSecondsAfterEmpty ..

쿠버네티스에서 민감한 데이터는 시크릿을 통해 관리됩니다. 생성된 시크릿은 mount fs 또는 env var 을 통해서 파드에 시크릿 데이터를 넘겨줄 수 있죠. 시크릿을 생성한 후, kubectl create secret generic secret1 --from-literal user=admin kubectl create secret generic secret2 --from-literal user=12345678 아래와 같이 yaml 을 작성해서 사용할 수 있죠. apiVersion: v1 kind: Pod metadata: creationTimestamp: null labels: run: pod name: pod spec: containers: - image: nginx name: pod resourc..

쿠버네티스에서 실행 중인 파드의 내용을 수정하려면 kubectl exec -it pod -- ... 를 통해 수정합니다. 만약 nginx 를 실행 중인 파드가 있고, nginx 의 index.html 을 수정하고 싶다면, 아래와 같이 진행을 할 것입니다. # pod 라는 이름을 가진 파드를 nginx 이미지를 이용해서 생성 kubectl run pod --image nginx # bash 를 통해 컨테이너 내부 접속 kubectl exec -it pod -- bash # index.html 을 검색 find ./ -type f -iname "*.html" # 위치를 찾은 후 vim 을 통해 수정 vim ./usr/share/nginx/html/index.html index.html 에 I'm kingbj..