개발을 하는데 있어 컨테이너는 더 이상 빠질 수 없을 만큼 중요한 개념이 되었습니다. 그리고 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) 입니다. 예를 들어, 쿠버네티스의 가장 기본..

쿠버네티스 환경에선 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 버전의 파이..

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

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

쿠버네티스 위에는 다양한 서비스들이 존재합니다. 이 서비스들이 하나하나 생겨나다 보면 어느 새 몇 백개, 몇 천개의 서비스들이 존재하게 됩니다. 이런 서비스들을 쉽게 관리하기 위해서 이스티오를 사용합니다. 이스티오는 서비스 메쉬 서비스 라는 타이틀에 걸맞게 다양한 기능들을 제공해주는데 이번 글에서는 그 중 핵심 기능 중 하나인 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 의 값을 인코딩해서 저장하는 이유는 해커에..

쿠버네티스 보안 관련 모범 사례를 살펴보면 아마 가장 기본적이고, 가장 많이 보이는 것이 하나 있습니다. 아마 쿠버네티스 뿐만 아니라 컨테이너를 사용하는 환경이라면 모두가 신경써야 하는 부분이죠. 바로 루트 계정 비활성화 입니다. 즉, 컨테이너 내 프로세스에서 루트 권한을 모두 비활성화 하는 것이죠. 컨테이너 내부에서 아무나 루트 권한을 사용하게 한다는 것은 모르는 사람에게 집 비밀번호를 알려주는 것과 다름이 없습니다. 예를 들어 컨테이너에 접속한 후 uname -a 명령어를 쳐보면 호스트의 OS 버전을 볼 수 있습니다. 루트 권한 비활성화는 이미지를 만들 때도 설정할 수 있고, k8s 로 파드를 배포할 때도 설정할 수 있습니다. 이번 글에서는 어떻게 루트 계정을 비활성화하고 안전한 파드를 만드는지 알아..

쿠버네티스에는 Audit 이라는 기능이 있습니다. 다들 눈치 채셨겠지만, Kube Api Server 에 어떤 API 를 호출했는지 감시하는 기능이죠. 쿠버네티스를 설치하면 기본적으로 제공 되지 않기 때문에 추가적으로 Audit 기능을 활성화 해주어야 합니다. 그래서 이번 글에서는 Audit 기능을 활성화해서 누가, 어떤 행위로, 어떤 리소스를 호출 했는지 감시해보겠습니다! 렛츠두더코드! Audit 기능 활성화 control plane & data plane v1.26.1 에서 진행되었습니다 쿠버네티스 공식 문서를 이동한 후 Audit 을 검색해줍니다. 그리고 클릭해서 문서를 확인합니다. 밑으로 쭉쭉 내려서 로그 백엔드 섹션으로 이동합니다. /etc/kubernetes/manifests/kube-apis..

매우매우매우 중요! Karpenter v0.32 버전부터 리소스 이름들이 변경되어 참고 바랍니다. 개념은 똑같습니다. (ex. Provisioners -> NodePools) AWS EKS 를 통해 클러스터를 구축하면 Data Plane (이하 Node) 를 다양한 방식으로 구축할 수 있습니다. Managed Node Group, Fargate 그리고 이러한 리소스를 유연하게 관리할 수 있게 해주는 AWS Auto Scaling, Karpenter 가 있습니다. 이번 글에서는 Karpenter 를 통해 AWS Auto Scaling 보다 유연하게 Node 를 관리하는 방법을 알아보고자 합니다. 우선 간단하게 알아보도록 하죠. 렛츠두더코드! Karpenter 가 뭐죠? 여기서 말하는 노드 == 인스턴스 ..

누구나 한번 쯤은 슈뢰딩거의 고양이에 대해서 들었거나 관련 밈을 보셨을 겁니다. 그래도 혹시 모르시는 분들을 위해 간단히 알려드리죠. 고양이를 보이지 않는 상자에 넣고, 그 속에 50:50 확률로 고양이를 죽이는 독극물을 넣었을 때 고양이는 죽을까요? 살까요? 일반 세계에서는 죽었다, 살았다 라고 표현하지만 양자역학 세계에서는 이를 죽음과 삶이 중첩된 상태라고 표현합니다. 즉, 살아있으면서 죽어있다 라고 합니다. 오늘 글에서 소개할 Fargate (파게이트) 또한 슈뢰딩거의 고양이와 비슷한 개념입니다. (나만 그렇게 생각할수도..) Fargate 는 무엇일까? 우리는 보통 AWS 를 이용해서 애플리케이션을 배포한다고 하면 EC2 를 통해 인스턴스를 생성하고, 그 인스턴스 내부에 컨테이너나 직접 프로세스로..

중요!! ARC 가 Github Official 프로젝트가 됨에 따라 아래에서 보여드린 ARC 관련한 리소스들은 전부 구 버전입니다. 여기를 참고해주세요! Action Controller Runner (이하 ARC) 는 파드 단위 Self Hosted Runner 입니다. 즉, 쿠버네티스 환경에서 파드를 Self Hosted Runner 로 지정할 수 있게 해주는 오픈소스죠. ARC 에 대한 정보는 여기를 확인해주세요. 근데 ARC 를 사용하는 경우 하나 고려해야 할 사항이 있습니다. 바로 ARC 에 의해 만들어지는 파드는 Github Action 의 Job 이 종료될 경우 제거되고 다시 생성됩니다. 따라서 HostPath 나 EFS 를 사용하지 않으면 Job 을 실행할 때 생성했던 Java SDK, N..

퍼블릭 클라우드 환경에서 쿠버네티스를 운영할 때 온프로미스보다 편한 점 중 하나가 바로 볼륨 관리 라고 생각합니다. EBS CSI Driver 를 설치 후 Storage Class, PV 그리고 PVC 를 통해 쉽게 AWS EBS 를 통해 볼륨을 언제 어디서든 가져다 쓸 수 있죠. 한편, 쿠버네티스에선 다양한 방법으로 볼륨을 사용할 수 있는데요. 컨테이너간 공유를 가능케 해주는 EmptyDir, 노드의 볼륨을 통해 파드간 공유를 가능케 해주는 HostPath, NFS 서버를 사용하는 NFS 기능 등이 있습니다. 그라파나를 노드에 배포할 때, 그라파나의 설정 파일은 그라파나가 배포된 노드의 볼륨에 저장이 됩니다. 따라서 만약 그라파나 파드가 다른 노드에 배포가 될 경우 이전에 가지고 있던 그라파나 설정을 ..

Istio 는 흔히 K8S 클러스터 내에서 서비스 메시 역할을 해줍니다. 서비스 메시 뿐만 아니라 Nginx Ingress, ELB Ingress 처럼 Ingress 역할 또한 해줍니다. Istio Ingress Gateway 가 정식 명칭이나 쉽게 Istio Ingress 로 지칭하도록 하죠 🤟 EKS 와 같은 퍼블릭 클라우드를 이용해서 Load Balancer Service 를 생성해주면 자동으로 CLB 가 할당됩니다. 따라서 Istio Ingress 또한 CLB 로 할당이 됩니다. CLB 는 앞으로 AWS 에서 deprecated 되기 때문에 Network Load Balancer(이하 NLB) 나 Application Load Balancer(이하 ALB) 로 대체되어야 합니다. 그래서 이번 글에..