지난 글에서는 proxmox 을 설치한 후, 쿠버네티스 클러스터를 생성했습니다. 이번에는 서비스 메쉬와 컨트롤러 역할을 해주는 Istio 와 CSI Driver NFS 를 설치합니다. Istio 는 Nginx Controller 를 대신하고, mTLS 와 같은 기능을 사용하기 위해 설치하고, CSI Driver NFS 는 파드들의 볼륨으로 사용하기 위해 설치합니다. Consul 을 도입해보고 싶은데 이건 추후 작업해보겠습니다!! 모든 작업은 IaC 로 관리하기 위하여 테라폼으로 진행됩니다! 렛츠두더코드~ Istio Helm 버전의 설치를 위한 가이드가 공식 문서에 잘 설명 되어 있습니다. Helm Provider 에 맞게 코드화를 진행했고, terraform apply 를 통해 배포했습니다. 굳이 혼자 ..

지난 글에서 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..

쿠버네티스에서는 환경 변수나 새롭게 작성한 파일을 컨테이너 내부에 전달해주기 위해서 Configmap, Secret 을 사용합니다. 이름에서 유추할 수 있듯 Configmap 은 보안적으로 중요치 않은 데이터들을 사용할 때, Secret 은 보안적으로 중요한 데이터를 사용할 때 사용합니다. 따라서 Configmap 은 Plain Text 로 데이터가 저장되는 반면, Secret 은 인코딩 되어 저장됩니다. 그래서 이번 글에서는 Secret 을 생성 후 어떻게 파드에게 전달하는 지를 알아보려고 합니다. 여담으로 Secret 의 인코딩 되는 방법은 사실 디코딩 하면 어떤 값인지 알 수 있기 때문에 보안적으로 안전하지는 않습니다. 쿠버네티스는 이렇게 굳이 Secret 의 값을 인코딩해서 저장하는 이유는 해커에..

EC2 인스턴스에는 보안 그룹을 설정하여 특정 트래픽만 인바운드, 아웃바운드를 허용할 수 있습니다. 인바운드 규칙과 아웃바운드 규칙은 아래와 같이 정의할 수 있죠. 그 중 소스 규칙을 한번 자세히 보죠. (아웃바운드에선 대상 규칙에 해당) CIDR 블록 같은 경우, 보안 그룹이 설정된 인스턴스에 인바운드로 트래픽이 올 때 소스 규칙에 명시된 CIDR 가 만족 되지 않으면 Deny 됩니다. 몇가지 예시를 살펴보죠. 0.0.0.0/0 으로 규칙을 정하면 모든 IP 로부터 들어오는 트래픽은 Allow 198.162.0.1/16 으로 규칙을 정하면 198.162.xx.xx 로부터 들어오는 트래픽은 Allow 118.220.38.110/32 으로 규칙을 정하면 118.220.38.110 로부터 들어오는 트래픽만 ..