하마롱크의 블로그

1. 쿠버네티스 DNS 1.1. 쿠버네티스에서는 클러스터 내부에서만 사용하는 DNS 설정 가능 1.2. 이를 통해 파드 간 IP가 아닌 도메인을 사용하여 통신하는 것이 가능해짐 1.3. 어떤 클러스터에 적용한 템플릿에서 파드 간 통신을 도메인으로 하도록 설정한다면, 수정 없이 다른 클러스터에서도 적용이 가능 1.4. 특정 파드나 디플로이먼트를 도메인으로 접근하도록 설정했다면, 문제가 생겨서 파드나 디플로이먼트를 재생성할 때 자동으로 변경된 파드의 IP를 도메인에 등록하여 새로 실행된 파드로 연결 가능t 1.5. IP로 통신하도록 설정했다면 IP 대역이 다른 경우, 템플릿에서 해당 IP 대역을 사용하도록 수정한 후 다른 클러스터에 적용해야 하므로 번거로움 1.6. DNS를 클라이언트나 API 게이트웨이가 ..

1.0. 인증(Authentification) 1.0.1. 사용자가 쿠버네티스의 API에 접근하려면 인증을 거쳐야 함 1.0.2. 외부에서 쿠버네티스 API에 접근할 수 있는 기본 포트는 6443이며, TLS 인증이 적용되어 있음 1.0.3. 쿠버네티스는 일반적인 사용자 계정과 서비스 계정으로 인증을 요청 1.0.4. 사용자 계정은 별도의 외부 인증 시스템에 있는 사용자 정보를 연결해 사용 쿠버네티스는 기본적으로 사용정보를 저장하지 않기 때문 별도 외부 인증 시스템 없을 시 파일에 사용자 이름과 비밀 번호 저장해 사용가능 1.0.5. 서비스 계정은 쿠버네티스가 직접 관리하는 사용자 계정 해당 서비스 계정에는 시크릿이 할당되어 비밀번호 역할을 함 1.1. kubectl의 TLS 인증 정보 구조 확인하기 1..

DevOps 방식에서는 정기적으로 여러 배포를 사용하여 '지속적 배포', 'Blue/Green 배포', 'Canary 배포'와 같은 애플리케이션 배포 시나리오를 관리한다. 여러 이기종 배포가 사용되는 일반적인 시나리오를 처리할 수 있도록 컨테이너를 확장해보고, 관리해보았다. 영역 설정 #영역을 us-central1-a로 설정 gcloud config set compute/zone us-central1-a 이 실습에서 사용할 샘플 코드 가져오기 gsutil -m cp -r gs://spls/gsp053/orchestrate-with-kubernetes . cd orchestrate-with-kubernetes/kubernetes #n1-standard-1 노드 3개로 클러스터 생성 gcloud contai..

GCP 문서를 참고하여 웹 애플리케이션을 Docker 컨테이너 이미지에 패키징하고 GKE 클러스터에서 컨테이너 이미지를 실행하고, 사용자 니즈에 따라 확장 가능한 부하 분산된 복제본 세트로서 웹 애플리케이션을 배포했다. 저장소 만들기 Artifact Registry에 이미지를 저장하고 레지스트리에서 배포한다. Artifact Registry는 Google Cloud에서 권장되는 Container Registry이다. hello-repo라는 저장소를 만들었다. gcloud artifacts repositories create hello-repo \ --repository-format=docker \ --location=us-west1 \ --description="Docker repository" 컨테이너..

에어컨 온도조절기와 같은 컨트롤 루프(control loop)는 특정 온도를 설정하면 에어컨을 켜거나 끄기를 반복해서 해당 온도를 맞춘다. 이러한 컨트롤 루프는 시스템의 상태를 조절하는 종료되지 않는 루프이다. 쿠버네티스에서 컨트롤러는 클러스터 의 상태를 관찰 한 다음, 필요한 경우에 생성 또는 변경을 요청하는 컨트롤 루프이다. 각 컨트롤러는 현재 클러스터 상태를 의도한 상태에 가깝게 만들어준다. 컨트롤러는 포드(Pod)를 관리하는 역할을 주로 하는데, 시스템이 아닌 포드를 실행하거나 종료시켜 원하는 서비스를 지원하는 것이다. 컨트롤러 패턴 컨트롤러는 하나 이상의 쿠버네티스 리소스 유형을 추적한다. 이 오브젝트는 의도한 상태를 표현하는 사양 필드를 가지고 있으며, 해당 리소스의 컨트롤러는 현재 상태를 의..

GKE에서 비공개 클러스터는 공개 인터넷에서 마스터에 액세스할 수 없도록 하는 클러스터이다. 비공개 클러스터에서 노드는 공개 IP 주소가 주어지지 않고 비공개 IP 주소만을 가짐으로써 격리된 환경에서 실행된다. 노드와 마스터는 VPC 피어링을 사용하여 서로 통신한다. Kubernetes Engine API에서 IP 주소 범위는 CIDR 블록으로 표현된다. 기본 영역 설정 gcloud config set compute/zone us-central1-a 비공개 클러스터 만들기 비공개 클러스터 중에서도 클라이언트가 공개 엔드포인트에 액세스할 수 없는 비공개 클러스터를 만들었다. 이는 공개 엔드포인트 액세스가 중지된 컨트롤 플래인에 대한 가장 제한된 액세스를 제공한다. 컨트롤 플래인의 공개 엔드포인트에 대한 클..

쿠버네티스를 배포하면 클러스터가 생성된다. 쿠버네티스 클러스터는 크게 마스터(Master)와 노드(Node) 두 개의 컴포넌트로 나누어진다. 마스터는 쿠버네티스의 설정 환경을 관리하고, 클러스터의 작업자 노드와 포드를 제어한다. 워커 노드는 애플리케이션 워크로드의 구성 요소인 포드를 호스트한다. 운영 환경에서 일반적으로 마스터는 여러 컴퓨터에서 실행되고 클러스터는 일반적으로 여러 노드를 실행하여 내결함성과 고가용성을 제공한다. 1. 마스터 컴포넌트 마스터 컴포넌트는 클러스터에 대한 전반적인 결정을 내리고, 이벤트를 탐지하고 응답하는, 클러스터 전체를 컨트롤하는 시스템이다. 1.1 kube-apiserver 쿠버네티스는 모든 명령과 통신을 API를 통해서 하는데 그 중심이 되는 서버가 API서버이다. AP..

쿠버네티스 핵심 기능 10가지 자동화된 롤아웃과 롤백(Automated rollouts and rollbacks) 쿠버네티스는 애플리케이션 또는 애플리케이션의 설정을 변경하는 경우, 점진적으로 롤아웃하는 동시에 애플리케이션을 모니터링해서 모든 인스턴스가 동시에 종료되지 않도록 보장한다. 만약 어떤 문제가 발생하면 쿠버네티스는 변경 사항을 롤백한다. 즉, 다운타임 없이 애플리케이션의 새로운 버전 및 설정에 대해서 롤아웃과 롤백이 가능하다는 것이다. 서비스 디스커버리와 로드밸런싱(Service discovery and load balancing) 쿠버네티스를 사용하면 익숙하지 않은 서비스 디스커버리 메커니즘을 사용하기 위해 애플리케이션을 수정할 필요가 없다. 쿠버네티스는 컨테이너에 고유한 IP를 부여하고, ..

비공개 클러스터는 내부 IP주소에만 의존하는 VPC 기반 클러스터 유형으로, 노드, Pod, 서비스에 고유한 IP주소 서브넷 범위가 필요하다. 비공개 클러스터는 외부 IP 주소가 없는 노드를 사용하므로, 인터넷의 클라이언트가 노드의 IP 주소에 연결할 수 없다. 공개 클러스터와 달리 비공개 클러스터에는 제어 영역 비공개 엔드포인트와 제어 영역 공개 엔드포인트가 모두 있다. 제어 영역의 비공개 엔드포인트에 고유한 /28 IP 주소 범위를 지정해야 하며 제어 영역의 공개 엔드포인트를 사용 중지할 수 있다. 그리고 노드가 내부 IP 주소를 사용하더라도 Load Balancer 유형의 외부 서비스나 외부 인그레스를 사용함으로써 외부 클라이언트가 클러스터의 서비스에 연결이 가능하도록 할 수 있다. 비공개 클러스터..

GCP 문서를 참고하여 GKE(Google Kubernetes Engine)의 클러스터 유형에 대해 정리해보았다. GKE 클러스털르 생성할 때, 클러스터의 유형 등 다양한 부분에 대해 선택할 수 있다. 일반적으로 클러스털를 만든 후에는 선택사항을 변경할 수 없으므로, 클러스터 생성시 선택사항을 잘 선택해야 한다. 이러한 선택사항은 가용성, 버전안전성, 네트워크에 영향을 미친다. 클러스터 관리 수준 생성하는 클러스터에 필요한 유연성, 책임, 제어의 수준을 파악하는 것이 필요하다. 필요한 제어 수준에 따라 GKE에서 사용할 작업 모드와 필요한 클러스터 구성을 결정할 수 있다. GKE에는 Autopilot과 표준 작업모드가 있다. Autopilot 모드: 완전 프로비저닝되는 관리형 클러스터 구성을 제공하며, ..