고슴도치 METHOD

Kubernetes 클러스터에서 다수의 Micro Service가 사용할 Disk(Volume)이 필요 한 상황이 생겼다. GCP에서 제공하는 관리형 NAS 서비스인 Cloud Filestore를 사용 하려 했으나 300GB 정도의 용량만 필요 한 상황에서 Filestore는 HDD 기본 시작용량이 1TB, SSD는 2.5TB에 비용도 꽤나 비싸서 사용을 보류 하였고, 200GB 표준 영구 디스크 기준으로 한달에 $8.00 만 청구된다고 하는 GCE-PD 서비스를 사용 해 보기로 했다. Cloud SDK가 설치되어 있는 클라이언트에서 아래 명령어를 실행 시킨다. $ gcloud compute disks create --size=300GB --type=pd-standard --zone={ZONE} {DIS..

컨트롤 플레인의 구성 요소는 여러 노드에 분산해서 구축이 가능하다. 쿠버네티스 컨트롤 플레인의 구성 요소 4가지 - API Server - Scheduler - Controller Manager - etcd 쿠버네티스 클러스터의 모든 구성 요소들은 오직 API 서버를 통해서만 통신한다. 라는게 중요한 개념이다. 또한 위 4가지 구성 요소들은 단일 서버가 아닌 여러 서버에 분산되어서 구축 될 수 있다. 따라서 여러 노드에 컨트롤 플레인의 구성 요소를 분산시켜 HA를 확보할 수 있다. 다만 이때 API server와 etcd는 동시에 병렬로 실행 가능 하고, Scheduler와 Controller Manager는 1개만 Active, 나머진 Stand by 형태로 유지된다는 점을 주의 한다.

FluentBit와 ELK 스택(ElasticSearch, Logstash, Kibana), Kafka를 활용한 로깅 시스템을 구축하는 방법에 대하여 기록하려고 합니다. 아직 작성중인 글입니다.

Istio Service Mesh(ISM)를 처음 접했을 때, 트래픽의 흐름이 어떤식으로 흘러가는지 파악하기 어려웠는데 지금까지 알게 된 내용들을 나름대로 정리 해보려 한다. 여기저기서 주워들은 지식들을 모아서 만든 자료이므로 틀린 부분이 있을 수 있어 이 글을 읽는 독자분들도 그 점을 인지하고 그저 참고용으로 사용하셨으면 합니다. 아래 내용은 GCP 기반 환경에서 해본 경험을 토대로 작성 되었습니다. - Istio를 도입할 경우 기능상의 여러 장점을 얻을 수 있지만, 그만큼 복잡한 구조와 지연시간이 늘어나게 됩니다. Inbound Traffic 1. istio-ingressgateway - Kubernetes 클러스터에서 외부와 통신하기 위해 내부적으로 지원하는 "Ingress" 라는 오브젝트는 ISM..

gcloud SDK 와 Docker가 설치 되어 있는 PC에서 진행하는 것을 전제로 합니다. 먼저 GCP 웹 콘솔에서 [API 및 서비스] 항목에 들어가 아래 GCR API를 활성화 해 줍니다. 아래 명령어로 gcloud 인증을 사용하도록 도커를 구성 합니다. $ gcloud auth configure-docker 그 다음 아래 명령어를 통해 가지고 있는 이미지에 태깅을 해 줍니다 $ docker tag [SOURCE_IMAGE] gcr.io/[PROJECT-ID]/[IMAGE:TAG] GCR에 PUSH(업로드) 해 줍니다. $ docker push gcr.io/[PROJECT-ID]/[IMAGE:TAG]

카프카 클러스터를 구성하기 위해 먼저 VM(CE)를 구성 해 준다. 총 4대의 VM이 필요하며 이 중 3대는 카프카 클러스터 구성용, 1대는 SSH 접속을 위한 Public IP가 부여된 VM이다. 폐쇄망 VM과 공개망 VM을 만드는 것은 따로 상세히 기술하지는 않는다. 주의 할 점은 카프카 클러스터 구성용 VM에는 각각 30GB의 외부 볼륨이 붙는다. 아래 사진 한장으로 설명을 대체 한다. 각 서버에 SSH로 접속하기 위해 edge 서버에서 몇가지 작업을 해야한다. 아래 순서대로 진행 한다. kafka 클러스터용 VM에 SSH로 접속하기 위한 키 생성 및 키 배포 작업. 클러스터용 VM에 외부 볼륨 마운트 후 kafka 계정 생성 작업. 편리한 SSH 접속을 위한 Script 작성 폐쇄망에 VM 3대에..

카프카 클러스터 구성을 위해 카프카 설치 영역과 데이터/로그 들이 모이는 영역을 분리해주는 작업을 하려고 한다. 계정 생성 등의 작업도 포함되어 있지만 주로 Volume Mount 쪽에 초점이 맞춰져 있다. 먼저 PV를 생성하고 VG안에서 LV를 나누는 순서로 구성한다. # 현재 Mount 된 Disk 목록 조회 g_cloud@kaf-com-dev-msq1:/$ sudo fdisk -l Disk /dev/loop0: 55.53 MiB, 58212352 bytes, 113696 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 5..

클라우드 운영 환경에서 로그 관리의 용이함을 위해 Kafka 애플리케이션의 Log를 Mount한 Volume 한곳에 모아두는 과정에서 이상한 점을 발견한다. Kafka에서 수집되어지는 로그 종류는 총 3 가지 정도로 보여지는데, 로그 위치를 지정 할 수 있는 옵션이 설정 파일들을 뒤져봐도 2 가지 밖에 없다는 것이다. 첫 번째는 server.properties 파일의 log.dirs 옵션이다. 이 로그 경로는 Kafka 애플리케이션의 자체 로그가 아니라 토픽, 파티션 정보등 Data가 저장되는 경로라고 이해 하는 것이 더 적합하다. 두 번째는 zookeeper.properties 파일의 dataDir 옵션이다. zookeeper에 관련된 로그들이 저장되는 경로이다. 세 번째로 kafka 애플리케이션의 로..

1. Kubernetes 에서의 Graceful 종료 설정 확인. 2. DB 에서 idle 설정 확인 3. Internal IP 설정 확인 작성중인 글입니다..

- 쿠버네티스 클러스터에 kube-system이라는 Namespace에는 kube-dns라는 Service 타입의 오브젝트가 떠있음. - 새로운 Service를 생성하게되면(svc-web이라는 서비스를 생성하였고 그 서비스의 IP는 10.96.100.100 이라 가정) 그 서비스의 정보인 [svc-web : 10.96.100.100] 이라는 정보가 kube-dns에 등록 되어짐. - 즉 svc-web.default.svc.cluster.local에 연결 해달라는것은 10.96.100.100에 연결해 달라는 것과 같다. - kube-dns 그 자체도 하나의 Service 타입 오브젝트이기 때문에 자체적인 Cluster IP를 가지고 있는데 그 IP는 보통 10.96.0.10 인 경우가 많다. - 모든 Po..