쿠버네티스에서 실행 중인 파드의 내용을 수정하려면 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) 로 대체되어야 합니다. 그래서 이번 글에..

쿠버네티스는 다른 플랫폼처럼 인증(Authentication)/인가(Athorization) 를 제공해줍니다. 따라서 인증받지 못한 사용자라면 401 (UnAuthorized) 를 응답 받고, 인증은 되었지만 권한이 없다면 403(Forbidden) 응답을 받게 되죠. 아주 평범한 인증/인가 프로세스입니다. 그런데 인증/인가가 완료되었다고쿠버네티스 환경에 바로 적용할 순 있는 건 아닙니다. 사용자가 보낸 요청을 적용하기 직전 한 군데를 더 들립니다. 그것이 바로 Adimission Controller 입니다. 이번 글에서는 Adimission Controller 에 대한 개념을 간단하게 설명하고, Adimission Controller 를 구현해볼 생각입니다. 😎 Admission Controller 가..

쿠버네티스를 공부하면서 처음 User Account 와 Service Account 를 접했을 때 단순히 쿠버네티스 API 서버에게 자격 증명하는 리소스인가보다 하고 넘어갔던 적이 있습니다. 이해가 안되서 그냥 넘어갔던.. 그래서 User Account 랑 Service Account 는 비슷한거 !! 같은 거 !! 라는 생각을 가지고 있었죠.. 하지만 이 둘은 분명 다릅니다. 쿠버네티스에는 쿠버네티스 내에 존재하는 자원에 대한 접근을 위한 2가지의 account 타입이 존재합니다. User Account Service Account 쿠버네티스 공식 문서에는 이와 같이 나와있습니다. 사용자 어카운트는 사람을 위한 것이다. 서비스 어카운트는 파드에서 실행되는 프로세스를 위한 것이다. 100% 맞는 말이지만..