Study/K8s

이번에는 Public Cloud의 Kubernetes 서비스와 로드밸런서 서비스의 연동을 진행해본다. Naver Cloud Platform(이하 NCP)의 Kubernetes 서비스, NKS를 이용해볼 것이며 로드밸런서에 SSL 인증서까지 연결하는 과정까지 진행해보도록 한다. 사용된 예제 ALB Ingress Controller 활용 예제 guide.ncloud-docs.com NKS 클러스터 생성 NKS에 클러스터를 생성하고, 이 클러스터에 접속해서 작업하기 위해 몇가지 선행작업이 필요하다. 1. ncp-iam-authenticator 설치 및 설정 NKS의 API를 호출하기 위해 IAM 인증이 필요하다. 이를 위해 ncp-iam-authenticator를 다운받아야한다. ncp-iam-authenti..

앞서 알아보았던 Service 중 외부 요청을 처리하기 위한 것에는 NodePort가 있었다. NodePort는 클러스터 내의 모든 노드에 특정 포트를 오픈시켜 외부로부터 접근할 수 있도록 하는 서비스이다. 이러한 방식으로 클러스터 내부 네트워크로 접근하는 방식에는 사실 몇가지 애로사항이 존재한다. 포트 사용 문제 NodePort는 각 서비스별로 하나의 포트를 고정으로 사용한다. NodePort 기본 정의에 따라 30000~32767 사이의 포트만 지정해줄 수 있다. SSL 인증서 사용 불가 이러한 애로사항을 해결해주기 위해 LoadBalancer 서비스를 사용할 수 있다. 하지만 LoadBalancer는 Public Cloud에 많이 의존하게 되는 것부터 노출시킬 서비스에 대해 각각 IP주소를 가진다는..

Helm kubernetes의 패키지 매니저, 배포하는 환경에 따라 설정값을 따로 정의해서 배포할 수 있도록 패키지 매니저 역할을 한다. Helm에서 패키지는 ‘Chart’라고 하며, chart는 kubernetes 애플리케이션의 리소스 정의로 이루어진다. Helm을 통해 Chart를 설치하는 과정은 Chart가 정의된 helm repo를 추가하고, 해당 repo를 통해 install한다. Helm 아키텍쳐 Helm 아키텍쳐의 구성요소에는 쿠버네티스 클러스터, Helm 클라이언트, Helm Chart Repository가 있다. Helm 클라이언트가 Chart Repository로부터 Chart를 다운로드받고, 이 Chart를 기반으로 쿠버네티스 클러스터의 API 서버와 통신해 Chart를 적용하게 된다..

컨테이너 설정파일을 관리하는 방법으로는 컨테이너 이미지를 빌드할때에 복사하거나, 컨테이너를 실행했을 때에 외부 호스트에서 파일을 연결해주는 방법이 있다. 쿠버네티스에서는 ConfigMap 리소스를 통해 설정파일을 관리하는 방법을 제공한다. ConfigMap 컨테이너의 환경설정 값을 저장하기 위한 리소스로 키-값 쌍의 데이터를 저장한다. ConfigMap에는 주로 Application의 설정값, 컨테이너의 환경변수, 설정파일과 같은 데이터를 저장한다. 아래는 ConfigMap을 정의하는 Manifest이다. apiVersion: v1 kind: ConfigMap metadata: name: nginx-config data: NGINX_PORT: "8080" NGINX_SERVER_NAME: "my-ngin..

이번에는 쿠버네티스에서 데이터를 저장하는 Volume을 정리해보도록 한다. Volume 컨테이너가 데이터를 저장하고 공유하는 방식을 제공하는 객체, 기존 컨테이너에서의 Volume과 유사하나 더 유연하게 사용할 수 있다. 이전의 Service를 정리했을때에 알아보았듯이 컨테이너는 일시적인 특성을 가져 일반적으로 컨테이너가 삭제되면 컨테이너에 저장된 내용들이 휘발되는 점이 존재한다. 특히나 데이터베이스와 같은 리소스는 파드나 컨테이너가 삭제되더라도 내부의 데이터를 보존을 해주어야하는데, 여기서 Volume을 사용하게 된다. 쿠버네티스에서 제공하는 Volume의 종류는 아래와 같다. emptyDir hostPath PV/PVC emptyDir 파드 내에서만 지속되는 컨테이너의 임시적인 데이터를 저장하기 위한..

Service 파드 집합에서 실행중인 Application을 네트워크 서비스로 노출시키는 방법, 네트워크 추상화를 제공해 동적으로 할당된 파드에 접근할 수 있는 리소스이다. Service의 목적 왜 이런 리소스가 필요할까? 서비스 리소스가 필요한 이유를 일반적인 상황을 통해서 알아볼 수 있다. 웹 Application을 구동시키는 클러스터를 운영하고 있다고 가정해보자. 그리고 이 Application이 Deployment나 StatefulSet을 통해 여러 파드로 분산되어 실행되고 있다고 할 때, 일부 파드가 재생성되는 상황을 생각해보자. 파드가 영구적이지 않은 특성(일회성)을 가짐에 따라, 클러스터의 상황에 따라 언제든지 다른 노드들로 옮겨질 가능성이 존재한다. 이렇게 다른 노드로 옮겨져 생성되면, 매..

쿠버네티스의 리소스 오브젝트를 생성하는 방법에는 kubectl CLI 커맨드로 생성하는 방법과 Manifest 파일을 적용해 생성하는 방법 2가지가 존재한다. 이번에는 Manifest 파일과 이를 통해 리소스 오브젝트를 생성하는 방법을 알아보도록 한다. Manifest 파일 Manifest 파일은 YAML / JSON 포맷으로 작성되는 쿠버네티스 리소스 오브젝트의 구성을 정의하는 파일이다. 생성하고자하는 쿠버네티스 오브젝트를 파일에 정의한 후, kubectl apply를 통해 클러스터에 Manifest 파일을 적용한다. kubectl apply -f ./deployment.yml apply 명령어로 마스터 노드에 있는 쿠버네티스 API 서버에 Manifest 파일 내용을 전달하고, 파일의 유효성을 검사한..

앞서 쿠버네티스의 전체적인 아키텍처와 클러스터, 노드, 파드를 알아보았다. 이번에는 쿠버네티스의 워크로드 리소스들을 정리해보고자한다. 먼저 쿠버네티스에서 워크로드는 클러스터에서 실행되는 Application을 의미하며, 이러한 하나의 워크로드는 파드 집합으로 구성된다. 주요 워크로드 리소스에는 ReplicaSet(레플리카셋), Deployment(디플로이먼트), StatefulSet(스테이트풀셋), DaemonSet(데몬셋)이 존재한다. ReplicaSet 레플리카셋은 파드의 수를 일정하게 유지시키는 데에 목적을 둔 워크로드 리소스이다. 그렇기 때문에 파드에 대한 가용성(Avability)을 보장한다고 볼 수 있다. 다음은 레플리카셋을 정의하는 매니페스트 파일이다. apiVersion: apps/v1 k..