Study_note

EKS 사용 고객 중 Multi Cluster 환경 도입 예정이여서 해당 환경 구성 방법과 운영 팁을 달라했던 문의가 있었다. 그럼 왜 Multi Cluster 환경을 구성할까? 예를들어 DEV, PRO 환경 처럼 환경 별로 구성이 다를 때 아님 서울과 버지니아 서로 다른 두 곳에서 클러스터를 운영할때 운영의 편리함으로 인해 Multi Cluster환경으로 구조하는 경향이 있다. Kubernetes 클러스터를 처음 생성하면 ~/.kube 디렉토리에 config 파일이 생성되는데 해당 config 파일은 kubeconfig 파일이며, Kubernetes 클러스터와의 연결에 대한 정보를 저장하는데 사용된다. 여기서 config파일은 Cluster(클러스터 정보들), User(클러스터에 접근할 유저들의 정보 ..

쿠버네티스를 사용하면 kubectl 명령어를 통해 api를 호출하고 다양한 리소스에 정보들을 확인한다. 하지만 운영을하게 되면 반복적으로 옵션 및 명령어를 사용해야할 때도 있는데 예를들어 특정 namespace에 속한 자원을 관리할 때 사용하는 -n 옵션 멀티 클러스터 구조에서 클러스터 변환시 사용되는 use-context 등 반복되는 작업들이 많이 번거로울 때가 많다. 단순히 api를 호출하는 kubectl 명령어 경우 k로 변수로 바꿔 사용하여 불편함을 해소하는데 위에서 설명한 예들은 이런 단순한 방법으로는 해결하지 못한다. 이런 불편함을 해소하기 위한게 많은 사람들이 쿠버네티스 플러그인들을 생성하였고 이러한 다양하고 많은 플러그인들을 관리하기 위해 생긴게 플러그인 패키지 관리자가 Krew이다 kre..

쿠버네티스에서는 여러 가용영역에 워커 노드들이 배포되어있는 클러스트 구조로 구성되어있다. 그렇기 때문에 하나의 노드 하나의 가용영역에서만 사용되는 EBS 볼륨은 다른 노드에 같이 마운트를 못하고 다른 가용영에 있는 워커 노드 또한 마운트 하지못한다 이러한 문제점들 때문에 EFS를 사용하여 해결한다. EFS는 여러 가용 영역에서 접근이 가능하며 여러 노드에서도 사용 가능한 파일 공유 스토리지다 그럼 어떻게 EFS를 EKS에 어떻게 마운트 할까? 이런 동작들은 EFS CSI Driver를 사용하여 연결 가능하다. EFS CSI Driver (CSI - Container Storage Interface) Kubernetes 클러스터가 EFS 파일 시스템을 관리할 수 있게 해주는 CSI 인터페이스를 제공하는 도..

Kuernetes Secret Secret은 상대적으로 configmap과 비교가 많이 되는데 configmap이 쿠버네티스에서 특정 정보를 보관, 저장하는 오브젝트라 하면 Secret은 보안 정보를 보관, 저장하는 오브젝트이다. 하지만 Secret은 보안 정보를 보관, 저장한다하여 암호화된채로 저장 되지 않고 Base64로 인코딩 되어서 보관되어지며 해당 파일을 가진 모든 사람이 해당 시크릿 파일에 접근 가능하여 굉장히 보안적으로 취약한 보관 방법이다. 이런 보안취약점 때문에 AWS Secrets Manager를 사용하여 Secrets Manager 내 저장되어있는 암호들을 Kuernetes Secret의 동기화여 사용하며 해당 시크릿을 파드에 마운트하여 사용한다. AWS Secrets Manager ..

예전에 aws에서 주최하는 쿠버네티스 핸즈온 세션에서 여러 주제로 강의를 해준적 있었다. 그중 보안에 대한 이해가 부족하고 iam 권한 할당과 irsa의 권한 할당 workflow를 이해하지 못해 공부해본다. 우선 IAM 권한 할당 workflow WorkFlow 및 구성 AWS-IAM-Authenticator AWS IAM 자격 증명을 사용하여 Kubernetes 클러스터에 인증하는 도구로 쿠버네티스의 RBAC 권한을 AWS IAM을 통해 제어할 수 있도록 해주는 도구이다 ( EKS에서는 자동으로 내장되어 있음 ) Client 사용자가 요청을 보내면 AWS-IAM-Authenticator Client가 AWS sts:GetCallerIdentity API endpoint에 대한 요청을 생성하고 요청에 ..

Helm Override 차트에 기존 values.yaml을 수정하지 않고 일부 값을 변경할때 사용 2가지 방법 존재 1. --set 옵션 사용하여 특정 값 변경 2. -f 사용할 파일 사용하여 특정 파일로 변경 --set 테스트를 위해 일반적인 차트를 릴리즈하고 기존 values.yaml 파일에서 지정했던 image=nginx를 --set을 사용하여 image=nginx:latest로 변경 제대로 차트들이 릴리즈 됐는지 보고 릴리즈를 통해 생성한 디플로이먼트들에 이미지를 확인하면 아래와 같이 --set을 사용하지않은 override 디플로이먼트같은경우 image=nginx --set을 사용한 override 디플로이먼트같은경우 image=nginx:latest로 생성된 것을 확인 가능 다음으로는 다른 ..