고슴도치 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 형태로 유지된다는 점을 주의 한다.

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

GCP GKE에서 여러 클러스터를 운영하다 보니 자주 쓰게되는 context 관련 명령어를 정리 한다. $ kubectl config current-context # 현재 컨텍스트 확인 $ kubectl config use-context var@one-dev-**** # var 계정으로 one-dev-cluster1에 연결 $ kubectl config use-context gke_one-dev-******_asia-northeast1-a_one-prod-**** $ kubectl config view # config 파일 출력 $ kubectl config get-contexts # context들 조회

회사에서 쿠버네티스를 다루다보니 집에서 테스트 환경을 만들어서 이것 저것 테스트해보고 싶은 생각이 들었습니다. 개인적으로 쓰고있는 서버는 1대인데 이걸 물리적으로 3대를 놓는건 현실적으로 불가능하고, 클라우드로 구축하자니 매달 비용이 발생하니 이것도 만만치 않습니다. 그렇다고 우분투에 KVM을 사용하여 가상환경으로 구축하자니 안그래도 리소스가 넉넉치 않은 개인서버에 하이퍼바이저라는 부담을 안겨주는거 같아 꺼려졌는데, 방법을 찾아보다 보니 싱글 노드로 쿠버네티스를 구축하는 방법이 있어서 이를 공유하고자 합니다. 전체적으로 kubeadm으로 일반적인 쿠버네티스 클러스터를 구성하는 방법과 다른 점은 없습니다. 다만 worker node를 join 하는 과정이 생략되고, control plane에 taint를 ..