728x90
728x90
퍼시스턴트 볼륨(PV)와 퍼시스턴트 볼륨 클레임(PVC) 데이터베이스처럼 파드 내부에서 특정 데이터를 보유해야 하는 상태가 있는(stateful) 애플리케이션의 경우 데이터를 어떻게 관리해야 할까 고민해봐야 한다. 예를 들어, MySQL 디플로이먼트를 통해 파드를 생성하더라도 MySQL 파드 내부에 저장된 데이터는 영속적이지 않다. 디플로이먼트를 삭제하면 파드도 함께 삭제되고 그와 동시에 파드의 데이터 또한 함께 삭제되기 때문이다. 이를 해결하기 위해서 파드의 데이터를 영속적으로 저장하기 위한 방법이 필요하다. 쿠버네티스는 워커 노드 중 하나를 선택해 파드를 할당하는데, 특정 노드에서만 데이터를 보관해 저장하면 파드가 다른 노드로 옮겨갔을 때 해당 데이터를 사용할 수 없게 되기 이를 해결하기 위한 일반적..
인그레스(Ingress) 인그레스(Ingress)는 일반적으로 외부에서 내부로 향하는 것을 지칭하는 단어이다. 예를 들어 인그레스 트래픽은 외부에서 서버로 유입되는 트래픽을 의미하며, 인그레스 네트워크는 인그레스 트래픽을 처리하기 위한 네트워크를 의미한다. 서비스 오브젝트가 외부 요청을 받아들이기 위한 것이었다면 ‘인그레스'는 외부 요청을 어떻게 처리할 것인지 네트워크 7계층 레벨에서 정의하는 쿠버네티스 오브젝트이다. 여기서 ‘처리한다'라는 문장에는 많은 기능이 내포돼 있는데 인그레스 오브젝트가 담당할 수 있는 기본적인 기능만 간단히 나열해보면 다음과 같다. 외부 요청의 라우팅: /apple, /apple/red 등과 같이 특정 경로로 들어온 요청을 어떠한 서비스로 전달할지 정의하는 라우팅 규칙을 설정할..
컨피그맵(Configmap), 시크릿(Secret): 설정값을 파드에 전달 설정값이나 설정 파일을 내 애플리케이션에 전달하는 가장 확실한 방법은 도커 이미지 내부에 설정값 또는 설정 파일을 정적으로 저장해 놓는 것이다. 하지만 도커 이미지는 일단 빌드되고 나면 불변의 상태를 가지기 때문에 이 방법은 상황에 따라 설정 옵션을 유연하게 변경할 수 없다는 단점이 있다. 이에 대한 대안으로 파드를 정의하는 YAML 파일에 환경 변수를 직접 적어 놓는 하드 코딩 방식을 사용할 수도 있다. 위처럼 환경 변수를 파드 템플릿에 직접 명시하는 방식도 나쁘지는 않지만, 상황에 따라서는 환경 변수의 값만 다른, 동일한 여러 개의 YAML 파일이 존재할 수도 있다. 즉, 운영 환경과 개발 환경이 다른 경우에 각각 디플로이먼트..
Namespace: 리소스를 논리적으로 구분하는 장벽 쿠버네티스에서는 리소스를 논리적으로 구분하기 위해 네임스페이스라는 오브젝트를 제공한다. 간단히 생각해서 네임스페이스는 포드, 레플리카셋, 디플로이먼트, 서비스 등과 같은 리소스들이 묶여 있는 하나의 가상 공간 또는 그룹이라고 이해하면 된다. 예를 들어 모니터링을 위한 모든 리소스들은 monitoring 이라는 이름의 네임스페이스에서 생성할 수 있고, 테스트를 위한 리소스들은 testbed 라는 네임스페이스에서 생성할 수 있다. 또는, 여러 개발 조직이 하나의 쿠버네티스 클러스터를 공유해 사용해야 한다면 조직별로 네임스페이스를 사용하도록 구성할 수 있다. 이렇게 여러 개의 네임스페이스를 사용하면 마치 하나의 클러스터에서 여러 개의 가상 클러스터를 사용하..
Service: 포드를 연결하고 외부에 노출 다른 디플로이먼트의 포드들이 내부적으로 접근하려면 서비스라고 부르는 별도의 쿠버네티스 오브젝트를 생성해야 한다. 서비스는 포드에 접근하기 위한 규칙을 정의하기 때문에 쿠버네티스에서 애플리케이션을 배포하기 위해서는 반드시 알아야 할 오브젝트이다. 핵심 기능은 다음과 같다. 여러 개의 포드에 쉽게 접근할 수 있도록 고유한 도메인 이름을 부여한다. 여러 개의 포드에 접근할 때, 요청을 분산하는 로드 밸런서 기능을 한다. 클라우드 플랫폼의 로드 밸런서, 클러스터 노드의 포트 등을 통해 포드를 외부로 노출한다. 서비스의 종류 ClusterIP 타입: 쿠버네티스 내부에서만 포드들에 접근할 때 사용한다. 외부로 포드를 노출하지 않기 때문에 쿠버네티스 클러스터 내부에서만 사..
POD vs Container 파드는 같은 리눅스 네임스페이스를 공유하는 여러 컨테이너들을 추상호된 집합으로 사용하기 위해서 사용한다. 포드 내의 컨테이너들이 네트워크 네임스페이스 등과 같은 리눅스 네임스페이스를 공유해 사용하기 때문이다. 즉, 도커에서 컨테이너들끼리 네트워크 네임 스페이스를 공유하여 동일한 네트워크 환경을 사용한 것 처럼 POD 내부의 컨테이너들도 같은 리눅스 네임스페이스를 공유해 사용한다. 완전한 앱으로써의 POD 하나의 포드는 하나의 완전환 애플리케이션이다. 만약 하나의 애플리케이션에 로그를 수집하는 기능이나, 변경사항을 갱신해야 하는 경우 포드의 주 컨테이너와 기능 확장을 위한 추가 컨테이너를 함께 포드에 포함시킬 수 있다. 이렇게 포드에 정의된 부가적인 컨테이너를 사이드카 컨테이..